What happens if i remove main from the package.json and just keep lib-esm and provide it's access via module? and then import this package in another package via import (and not require())? Will this fail in older browsers? hence, I must keep both lib and lib-esm? - Also, I read on the internet that main is used when we import this package using require() and module is used when we import it using ES6 import? is this correct? is this the only relevance of main and module? I don't think so though, but couldn't find more on it. Thank you!
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.
What happens if i remove main from the package.json and just keep lib-esm and provide it's access via module? and then import this package in another package via import (and not require())? Will this fail in older browsers? hence, I must keep both lib and lib-esm? - Also, I read on the internet that main is used when we import this package using require() and module is used when we import it using ES6 import? is this correct? is this the only relevance of main and module? I don't think so though, but couldn't find more on it. Thank you!
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