yes, javascript has evolved over the years and since version 6 supports modules out of the box. NPM has started as a package manager for node.js, so there were module systems before ES6 that solved the needs of the backend more or the frontend. If you're using typescript I would go for import-statements instead of require(). You're saving yourself some time if you start building with typescript, let babel take care of downwards compatibility (Babel is what's used in create-react-app under the hood) and learn the details of the javascript ecosystem later on =)
so, I have package1 and CRA. CRA imports package1. and package1's package.json just have module: "lib-esm/index.js" and no main. and CRA is in typescript. So, when babel (which react uses internally) will build my code, will it also provide downward compatibility for the es6 code I had imported = package1 = available as ES6 and not ES3 bcoz I am only exposing "lib-esm/index.js"? - so, I can safely do this in my monorepo right? w/o worrying about browser compatibility issues when running my CRA app?
good question. I haven't tested your particular case yet, but I'd recommend having both module and main if your app is build against esm and before: The problem here is that it depends on which code babel runs on. If you're running a full build, then dependencies are baked (and minified etc) into the different chunks for your app. If you're just running in development, it might pull in modules, and you can run into problems for example when an es6-class (which is native to the browser) is extended like a non-native class (because js didn't always have classes). Somewhere I read a statement from the CRA team saying that they try to create builds for the largest common denominator of configurations (Browser/OS) out there - so that means ES6 modules and classes, because both are pretty standard now
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
yes, javascript has evolved over the years and since version 6 supports modules out of the box. NPM has started as a package manager for node.js, so there were module systems before ES6 that solved the needs of the backend more or the frontend. If you're using typescript I would go for import-statements instead of require(). You're saving yourself some time if you start building with typescript, let babel take care of downwards compatibility (Babel is what's used in create-react-app under the hood) and learn the details of the javascript ecosystem later on =)
so, I have package1 and CRA. CRA imports package1. and package1's package.json just have module: "lib-esm/index.js" and no main. and CRA is in typescript. So, when babel (which react uses internally) will build my code, will it also provide downward compatibility for the es6 code I had imported = package1 = available as ES6 and not ES3 bcoz I am only exposing "lib-esm/index.js"? - so, I can safely do this in my monorepo right? w/o worrying about browser compatibility issues when running my CRA app?
good question. I haven't tested your particular case yet, but I'd recommend having both module and main if your app is build against esm and before: The problem here is that it depends on which code babel runs on. If you're running a full build, then dependencies are baked (and minified etc) into the different chunks for your app. If you're just running in development, it might pull in modules, and you can run into problems for example when an es6-class (which is native to the browser) is extended like a non-native class (because js didn't always have classes). Somewhere I read a statement from the CRA team saying that they try to create builds for the largest common denominator of configurations (Browser/OS) out there - so that means ES6 modules and classes, because both are pretty standard now