Is it still necessary to put in so much work to precompile packages for NPM?

Question

Is it still necessary to put in so much work to precompile packages for NPM?

As I delve into a new project, the idea of numerous npm packages looms ahead. However, my approach is shifting towards eliminating pre-compiled files. Within the src directories of these packages, only d.ts, ts, js, and mjs files will reside - a radical departure from tradition motivated by both laziness and a belief that the time has come to halt pre-compilation entirely.

The question arises: how many variations must be tailored? ESModules, AMD, CommonJs, SystemJS? My simple inclination suggests leaving it untouched (import x from 'x', export foo = 123), entrusting developers with the necessary tools (Babel, Typescript) to handle integration efficiently, wouldn't you agree?

The second quandary stands at the brink: to what extent should these packages be compiled? Should we aim for ES3 or push forward to ES6 compatibility, catering solely to users on modern browsers? Is implementing differential loading the key solution here, despite its common association with HTML files rather than selectively used developer packages?

To simplify, do we truly need to invest extensive effort in this regard? Where does the lowest common denominator lie currently? While concrete statistical data eludes me, it appears that most projects employ some form of compiler/preprocessor like Babel or PostCss. What are your thoughts on this matter?

javascript typescript npm precompile es6-modules

Answer 1

Answer №1

In today's technological landscape, CommonJS and ES modules stand out as crucial technologies. Opting to forego CommonJS means you can navigate without the need for transpilation. Nevertheless, many frameworks and libraries still heavily rely on CommonJS and are unable to utilize ES modules.

To take a more lightweight approach, consider the following steps:

Firstly: Start by defaulting to writing everything as ES modules and structuring your package to be utilized primarily as ES module(s) (e.g., specify "type":"module" in your package.json and use .mjs as the file extension).

Next: Utilize Babel solely to generate a CommonJS fallback of your modules. The process may entail:

Integrate the subsequent dev dependencies into your project:

npm install --save-dev @babel/cli @babel/core @babel/plugin-syntax-import-meta @babel/plugin-transform-modules-commonjs

Subsequently, insert the following snippet into your package.json:

"babel": {
    "plugins": [
        [ "@babel/plugin-transform-modules-commonjs" ],
        [ "@babel/plugin-syntax-import-meta" ]
    ]
}

You can then transpile your ES modules to CommonJS using a simple line of shell code:

# assuming that your ES modules reside within the lib/ directory
for script in $(find lib/ -iname '*.mjs' | grep -v test.mjs | sed -e 's|.mjs||g'); do
    npx babel $script.mjs > $script.cjs
done

This process can also be added as a script in your package.json.

"scripts": {
    "build": "for script in $(find lib/ -iname '*.mjs' | grep -v test.mjs | sed -e 's|.mjs||g'); do npx babel $script.mjs > $script.cjs; done"
}

Execute this by running npm run build, incorporating it as a commit hook, executing it before pushing to the NPM registry, or even building to a separate folder from where your ES modules exist and excluding that folder via .gitignore.

This technique was how I developed several of my libraries (due to the same reasons mentioned), and it functions seamlessly in both CommonJS and ES module environments.

On another note, NodeJS offers documentation on deploying packages as both ES modules and CommonJS: https://nodejs.org/api/esm.html#esm_dual_commonjs_es_module_packages

Answer 2

In today's technological landscape, CommonJS and ES modules stand out as crucial technologies. Opting to forego CommonJS means you can navigate without the need for transpilation. Nevertheless, many frameworks and libraries still heavily rely on CommonJS and are unable to utilize ES modules.

To take a more lightweight approach, consider the following steps:

Firstly: Start by defaulting to writing everything as ES modules and structuring your package to be utilized primarily as ES module(s) (e.g., specify "type":"module" in your package.json and use .mjs as the file extension).

Next: Utilize Babel solely to generate a CommonJS fallback of your modules. The process may entail:

Integrate the subsequent dev dependencies into your project:

npm install --save-dev @babel/cli @babel/core @babel/plugin-syntax-import-meta @babel/plugin-transform-modules-commonjs

Subsequently, insert the following snippet into your package.json:

"babel": {
    "plugins": [
        [ "@babel/plugin-transform-modules-commonjs" ],
        [ "@babel/plugin-syntax-import-meta" ]
    ]
}

You can then transpile your ES modules to CommonJS using a simple line of shell code:

# assuming that your ES modules reside within the lib/ directory
for script in $(find lib/ -iname '*.mjs' | grep -v test.mjs | sed -e 's|.mjs||g'); do
    npx babel $script.mjs > $script.cjs
done

This process can also be added as a script in your package.json.

"scripts": {
    "build": "for script in $(find lib/ -iname '*.mjs' | grep -v test.mjs | sed -e 's|.mjs||g'); do npx babel $script.mjs > $script.cjs; done"
}

Execute this by running npm run build, incorporating it as a commit hook, executing it before pushing to the NPM registry, or even building to a separate folder from where your ES modules exist and excluding that folder via .gitignore.

This technique was how I developed several of my libraries (due to the same reasons mentioned), and it functions seamlessly in both CommonJS and ES module environments.

On another note, NodeJS offers documentation on deploying packages as both ES modules and CommonJS: https://nodejs.org/api/esm.html#esm_dual_commonjs_es_module_packages

Answer 3

Answer №2

When considering your audience and the technology they use, it's important to keep in mind compatibility issues. For instance, if you are coding with language features supported by Node v19 but not by Node v12, integrating your code could potentially break their application.

What is currently the lowest common denominator?

By pre-transpiling your code and defining the lowest-supported platform using browserslist, you can ensure that any unsupported features will be polyfilled with core-js or transpiled with tools like Babel, avoiding any potential code breaks.

The answer to "what is currently the lowest common denominator" is unique to each product and business. Some applications can set their own minimum requirements, while others must cater to a wider audience with varying tech capabilities.

As for "how many variations to make," focusing on creating versions in es and commonjs is advisable. Users can benefit from the more modern syntax of es (even when transpiled), with the hope that the usage of commonjs will eventually phase out completely, possibly within the next ~5 years as of 2023.

Answer 4

When considering your audience and the technology they use, it's important to keep in mind compatibility issues. For instance, if you are coding with language features supported by Node v19 but not by Node v12, integrating your code could potentially break their application.

What is currently the lowest common denominator?

By pre-transpiling your code and defining the lowest-supported platform using browserslist, you can ensure that any unsupported features will be polyfilled with core-js or transpiled with tools like Babel, avoiding any potential code breaks.

The answer to "what is currently the lowest common denominator" is unique to each product and business. Some applications can set their own minimum requirements, while others must cater to a wider audience with varying tech capabilities.

As for "how many variations to make," focusing on creating versions in es and commonjs is advisable. Users can benefit from the more modern syntax of es (even when transpiled), with the hope that the usage of commonjs will eventually phase out completely, possibly within the next ~5 years as of 2023.

Is it still necessary to put in so much work to precompile packages for NPM?

Answer №1

Answer №2

Similar questions

Working with DOM Element Selections in AngularJS

Is it guaranteed that npm install will consistently fetch the most recent compatible version of a dependency?

"Searching for the index of a clicked element? Here's how to do

Transmit information through a socket and await a response

jquery method to make entire navigation bar clickable

Using lambdas in JSX attributes is not allowed because it can negatively impact rendering performance

Unusual shadow cast by the box's silhouette

Using the ngClass directive with a conditional statement: Select 'class1' if true, otherwise select 'class2'

Using .after() in AngularJS for nested ng-repeat recursive iteration

Package.json file missing in root directory causing absence of readme data

What is the best way to determine the quantity of request query parameters in an express.js application?

Tips for validating an object with unspecified properties in RunTypes (lowercase object type in TypeScript)

"Encountering the error of 'require is not defined' in an Electron-React-Webpack-Typescript application when utilizing

Using optional function arguments with destructured arguments in TypeScript can result in throwing an error

React search form submits separate search each time a new input is is added to the form

The connection between two arrays remains intact even after using the .push() method in JavaScript or Vue.js

Using addClass and fadeIn simultaneously when hovering over an element

What are the steps for implementing Kotlin + React + Redux with create-react-kotlin-app?

Running an npm audit on the project reveals numerous errors and vulnerabilities

Facing a problem with the carousel in Angular 6

Is it still necessary to put in so much work to precompile packages for NPM?

Answer №1

Answer №2

Similar questions

Working with DOM Element Selections in AngularJS

Is it guaranteed that npm install will consistently fetch the most recent *compatible* version of a dependency?

"Searching for the index of a clicked element? Here's how to do

Transmit information through a socket and await a response

jquery method to make entire navigation bar clickable

Using lambdas in JSX attributes is not allowed because it can negatively impact rendering performance

Unusual shadow cast by the box's silhouette

Using the ngClass directive with a conditional statement: Select 'class1' if true, otherwise select 'class2'

Using .after() in AngularJS for nested ng-repeat recursive iteration

Package.json file missing in root directory causing absence of readme data

What is the best way to determine the quantity of request query parameters in an express.js application?

Tips for validating an object with unspecified properties in RunTypes (lowercase object type in TypeScript)

"Encountering the error of 'require is not defined' in an Electron-React-Webpack-Typescript application when utilizing

Using optional function arguments with destructured arguments in TypeScript can result in throwing an error

React search form submits separate search each time a new input is is added to the form

The connection between two arrays remains intact even after using the .push() method in JavaScript or Vue.js

Using addClass and fadeIn simultaneously when hovering over an element

What are the steps for implementing Kotlin + React + Redux with create-react-kotlin-app?

Running an npm audit on the project reveals numerous errors and vulnerabilities

Facing a problem with the carousel in Angular 6

Is it guaranteed that npm install will consistently fetch the most recent compatible version of a dependency?