Hey!

Thanks for your PR. You are targeting branch "7.3" but it seems your PR description refers to branch "7.4".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

Could you give an example to illustrate ?

all js/css lib to require without esm.
I saw some issues where asked too.
For CSS files it avoid to specify all one by one and omit if new one appear

example : #57604

With the flex update, it will be possible to require external js and css from a bundle

So... I'll quote the documentation of AssetMapper here

• Mapping & Versioning Assets: All files inside of assets/ are made available publicly and versioned
• Importmaps: A native browser feature that makes it easier to use the JavaScript import statement

This PR allow AssetMApper to deal with "no modules" libraries,

Then this should not be done in the importmap command / classes. As it is fundamentally different from what this package is about. I don't think we would add a sendSms() method in the Mailer package. This is the same level of difference

With the flex update, it will be possible to require external js and css from a bundle

This is outside importmap responsibility, and should imho stay that way.

ImportMap package is made to handle.... import maps (meaning modules).

<personal note>
If people want to work on a better DX for bundle users, and want to spend time working on that, they can open PR / discussions... I even have a couple ideas / promising concepts: but they do need people with time and desire to work on it, and will require bigger changes / new features in the component.

But bringing "hidden features"* in AssetMapper / ImportMap because it feels a "quick way" to do things from the bundle editor perspective seems weird to me.. what i mean by hidden features is "things never asked by end-users, or that are outside the scope of this component, and that are only technical methods for one goal: automate download of assets for bundle editors wanting to force that after composer install -- again, not the goal of this component.
</personal note>

--

On the implementation side, i think it would be best to isolate this code in another part of the component.

Correct me if I miss understood something here, but as i read the PR code, "full" type does not seem to be a package type like the existing others and i'm not sure we should have it mixed with CSS and JS, that are used for other purpose here. Using it as command option would allow unpredictable things like asking for a CSS file as FULL type, right?