search

jspm / project

Roadmap and management repo for the jspm project
161 stars 8 forks source link

Question: Deep import format #80

Closed gingur closed 4 years ago

gingur commented 4 years ago

Somewhat related to my original question https://github.com/jspm/project/issues/79, I was wondering if there is a reason the format of the deep import from a module like https://jspm.dev/react@16 as /npm:object-assign@4!cjs? If I used importmaps I worry I would have to define one for object-assign@4 and /npm:object-assign@4!cjs

guybedford commented 4 years ago

@gingur it's to support Node.js conditional export branches between "require" and "import" which can resolve different modules. See https://nodejs.org/dist/latest-v14.x/docs/api/esm.html#esm_conditional_exports.

The CLI coming out maybe even this month I hope will automatically do this handling when generating the import map.

gingur commented 4 years ago

I think I understand the reasoning for the format, I'm curious if it adds a lot of overhead to let the non-formatted version automatically detect when requested? Seems like that would resolve the concerns around having multiple import map definitions. Also, is there a potential issue if a semver minor / patch updates the package.json exports and possibly changes the conditions? I assume the parent caches the export condition of the deeply imported children at build time, and doesn't update when children dependencies update?

guybedford commented 4 years ago

This is why the marker is always in the URL, and only resolved without !cjs once within the versioned package itself. Because otherwise a package update could change the resolution and you wouldn’t be able to get that New resolution applied.

It did add a huge overhead having these emitted for every package yes, but there was no other way to do it without introducing the potential for breaks.

On Fri, Sep 18, 2020 at 17:57 Troy Rhinehart notifications@github.com wrote:

I think I understand the reasoning for the format, I'm curious if it adds a lot of overhead to let the non-formatted version automatically detect when requested? Seems like that would resolve the concerns around having multiple import map definitions. Also, is there a potential issue if a semver minor / patch updates the package.json exports and possibly changes the conditions? I assume the parent caches the export condition of the deeply imported children at build time, and doesn't update when children dependencies update?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jspm/project/issues/80#issuecomment-695141361, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAESFSSYNQQU7LNTHPCQC7DSGP6WDANCNFSM4RSVNARA .

guybedford commented 4 years ago

Happy to answer any questions further here you might have. If you're interested in the private release join the Discord to get the access announcements to the CLI when that work is released for testing.