build esm only #11
build esm only #11
Conversation
|
I disagree. System.register modules are an emulation of ESM modules. I maintain systemjs and the esm-bundle organization exists partially because the systemjs community uses it. |
|
That's fair. you should update the docs to specify that any package that uses deep module reference cannot be published using this technique. This module should be deprecated on npm. |
Are you referring to the |
Yes. The reason why is that
import compose from 'crocks/helpers/compose';
If a user implements so TL;DR: in order not to break |
You have completely misunderstood what I've been saying. I am okay with supporting deep module references. However, I have a strong preference towards doing so with babel instead of bash. See related #18 where I explain how this can be done. |
I'm happy to be corrected Will the approach in #18 produce
And I'm supposed to tell users to install a babel plugin that transforms their import specifiers? |
No - babel would be run instead of rollup as part of the build process for
Yes, the approach in 18 can produce both
{
"env": {
"esm": {
"plugins": ["babel-esm-plugin"]
},
"system": {
"plugins": ["@babel/plugin-transform-modules-systemjs"]
}
}
}
{
"scripts": {
"build": "concurrently -n w: 'build:*'",
"build:esm": "cross-env BABEL_ENV=esm babel src --out-dir esm --source-maps",
"build:system": "cross-env BABEL_ENV=system babel src --out-dir system --source-maps"
}
}
|
forgive my persistence, but this is the part I'm having trouble understanding If the build process produces import compose from 'https://unpkg.com/@esm-bundle/crocks/helpers/compose?module';Instead, wouldn't I have to // potentially breaks because of internal deep references
import compose from 'https://unpkg.com/@esm-bundle/crocks/esm/helpers/compose?module'; |
|
Yes you'd have to use https://unpkg.com/@esm-bundle/crocks/esm/helpers/compose. Why is that a problem? I don't think you'd need unpkg's |
Right. This will break apps. System.js is fine-and-dandy, but I want JavaScript modules that come-as-they-are. Please deprecate the package I'll have to find another way for this library. |
|
You seem upset / disappointed. I’m open to making changes, but need to understand why before doing so. Thus far you have insisted that my approach will break things, but you have not offered an explanation why. I don’t think that making dramatic statements (“deprecate the package”) is helpful in communicating. If there’s a valid use case for removing the esm directory, I’m open to doing so. But I need an explanation why. I think the main reason why we’re struggling to communicate effectively is because we use ES modules differently. Here is how I use ES modules: I use the esm-bundle packages within the browser, not in a bundler. I use import maps to control the url to the directory of the package (which includes the /esm/ directory). Then I can do things like How are you importing the modules? As in-browser modules? Or are you using a bundler like webpack / rollup? Or maybe are you using the nodejs implementation of modules? Something else? |
Not gonna lie, I had hoped to make a home here :) I have lots of ideas for packages that would benefit from this treatment.
True, I apologize for the charge in the words. it's a stressful time and you don't need me adding to that.
This library can be used in node (native or with esm polyfill or babel-register) or on the browser, and it uses the es module spec that includes deep module references. e.g. Really, my hope here is that anyone can take any CJS package, transform it to ESM as I've proposed to do (implementation of that transform is irrelevant, only the outputs concern me), and then use that package exactly as they would have the cjs modules in other circumstances So in the specific case of crocks, I use This closed PR is therefore a blocker for apollo-elements/apollo-elements#57 TL;DR: I use es modules as es modules. Not as modules with import maps, or as modules with build-time usage caveats. It's my hope that I'll be able to use this project to convert any CJS package to esm, and use it without changing anything about the consumer asides from the npm package reference in package.json. Requiring an additional step like import maps or build-time aliasing kind of defeats the purpose for me. So if I have to change the bundler to alias imports to Communication, Nomenclature, and the Purpose of this ProjectI think import maps and build-time aliasing are good and worthy tools, I just wouldn't want this project to require them, given this project's "pitch". I think part of my confusion and disappointment here stems from the name of this project. I think SystemJS is great. I use it, think everyone should use it for I also think that the way this project should do that is by providing es modules as es modules, and that includes deep module references, which necessitates preserving directory structure. I hope I've done a good job expressing my view without projecting anger. If I've failed at either of those conditions please let me know (I'm not angry) And please take care of yourself during this general quarantine ❤️ |
My very first sentence in the initial esm-bundle blog post says that esm-bundle provides System.register modules:
Since you've challenged the name of the project, I will point out that a bundle is a concatenation of files, which is not what your code does. The project is called esm-bundle, but your proposal is to not bundle at all, so as to allow for deep module references. Which is in direct contradiction to the stated purpose, existing code, and even the name of this project. I am open to the purpose evolving over time, but I don't think telling me that I haven't explained my idea well is useful. I wrote a blog post, documentation, and a template repo. You have deviated from that by 1) not bundling, and 2) not outputting System.register modules. You are the one who is proposing change to the purpose of the project, not me.
What benefit is there to server-side node code using ESM instead of CJS? The existing CJS packages work perfectly fine. I agree that using ESM in Node is desireable and likely the future for npm packages, but I don't see any reason to forcibly convert older packages to it. I write ESM for new node packages, and cjs for existing ones where I don't want to rewrite them. The nodejs team has done a good job of packages interop-ing with each other regardless of module format. In contrast, browser-side javascript simply cannot use CJS, but can use ESM. That is the inspiration for the esm-bundle project. One benefit of ESM is tree-shaking, but since nodejs projects often don't bundle their dependencies into their published tarball, I don't see how that would help in NodeJS either. Are there benefits I am missing? |
|
Look, I don't really mind if you don't want to support the whole spec, I just think that it would be better not to publish a package that says in the README that it's a drop-in replacement when doing so would actually break examples from that package's documentation: https://crocks.dev/docs/getting-started.html#single-entities-js-modules So that's why I think it would be best to deprecate this package. That way I can find a better way to publish It was a mistake to publish this package under this scope. I clearly misunderstood your purpose here. |
Again, you are critiquing my work. I did not say that this was a "drop-in replacement for any package." I said that this provides esm bundles of packages.
What spec are you referring to? A package's documentation is not a spec. esm-bundle is for browser bundles.
You did not answer this question - instead you just critiqued my work and referenced a spec that doesn't exist |
|
I am no longer going to engage with you on this - every one of your comments blames me for you not reading the blog post and docs. You are unable to explain why the esm directory breaks anything, and blame me for things that I and my documentation doesn't say. esm-bundle is not intended for nodejs usage, since ESM has no advantages in Node over CJS. |
see #1 (comment)
in order to match with the original package, i think this should only output esm, not system
crocks/helpers/compose fails to load, it has to be crocks/esm/helpers/compose, which breaks compatibility