nanoid: v4 can't be imported in node

This is a feature, not a bug. See the changelog for details of the breaking change in version 4.0 (semantic versioning major increment): https://github.com/ai/nanoid/blob/main/CHANGELOG.md#40

Really terrible decision. Was gonna use this in place of shortid because apparently this is more secure? But since I literally can’t import the latest I’m just gonna keep using shortid. Good luck building a product that people can’t use!

I think this decision was made far too early. ESM has just started to be supported by NodeJS. I’m not sure if I want to refactor my whole “production application” for ESM right now.

I just wanted to point that out.

Use this version while the author fixes commonjs issue:

npm i -S nanoid@^3.0.0

This is a feature, not a bug. See the changelog for details of the breaking change in version 4.0 (semantic versioning major increment): https://github.com/ai/nanoid/blob/main/CHANGELOG.md#40

Check your TS config.

Seems like TS convert import in source TS sources to require. I use this option in tsconfig.json: "module": "esnext" (buy you may need to convert the whole app to TS).

. I’m not sure if I want to refactor my whole “production application” for ESM right now.

“We will support 3.x branch with CommonJS for users who can’t migrate to ESM”

https://github.com/ai/nanoid/blob/main/CHANGELOG.md#40

So much hate, disrespect and general crying while you can just downgrade 1 version and have (almost) the exact same thing, as the only thing that you’d benefit from v4 is the reduced package size - which is actually a few bytes. There are no security fixes, no additional features that you’ll miss. What’s the point?

And that’s not all! This repository is under MIT license so you can just grab it and have your own version if you rely so much on it. You can apply any security fixes that would come up to v4. And there’s more! The package is basically a single 85 LOC file which you could adjust to do whatever you want it to do.

Unbelievable 🙄

Maybe you should remove "esModuleInterop": true,. Try to call tcs file.ts to be sure that you have import in the compiled results.

Here is one of my examples https://github.com/hplush/slowreader/blob/main/tsconfig.json

The entitlement from some of the assholes in this thread is unbelievable. I’m running into this issue myself and yes, it’s causing some minor pain. But it would never occur to me to yell at the maintainer and demand changes. Show some fucking respect people.

Theres no harm in supporting commonJS neither does it has any performance ,build or maintainability problems. Its too early to move into ESM imo

Dual ESM/CJS packages is not a good thing. As a developer of dual-publish I can say it without a doubt.

1. You need to duplicate every file in npm package which increase node_modules size.
2. It leads to expected problems in some non-standard systems (for instance, Jest is using custom ESM resolver and dual packages could increase the error rate).
3. Dual packages requires extra build step (like dual-publish or babel). With ESM-only you can publish your repository directly.
4. It also make more complex another tools. For instance, Size Limit will require extra plugin.
5. There is no simple way to use version from repository (for instance, to test PR) without some painful bugs. Because dual packages requires build step.

Current state of ecosystem when we need to support both ESM and CJS is very hard for maintainers. Our community need to migrate to ESM-only future. It was already a few years since ESM announce.

💩

Understand and respect the author’s choice, even if I can downgrade to v3, I probably won’t use this product again. Hope to find a good replacement soon.

Hello @g012 , have you seen this doc? https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

Support for ESM depends heavily on tooling, for example you may have different tsconfig.json settings for your unit tests, your dev builds, and your production release … depending on whether your codebase is managed with WebPack, Rollup, Vite, Jest, Vitest, etc.

The author of NanoID said that he will kindly continue to offer off-the-shelf compatibility with CommonJS by maintaining v3 in parallel to ESM v4, but I am concerned that noise/signal ratio will increase in this issue tracker due to v4 support queries.

As far as I can tell there are no problems with NanoID’s published package.json export map etc. so I think it would make sense to continue such general ESM/CJS conversations in a GitHub discussion instead.

😃

To tell a joke, the software forces the platform to support his software to solve the problems encountered by users.

I found the author to be a double standard person. I hope that the “nanoid” package will no longer appear in my software, especially Node-based backend projects. At least most of the packages I use are built using TS, and support will gradually increase with platform upgrades. These packages developed using TS make my work happy. nanoid makes me desperate to find a replacement.

Are you planning any security updates for 3.x? Can you clarify what you mean with ‘support 3.x branch’?

Of course. All fixes will be backported.

Whatever works for the maintainer. I am happy the person still maintains the CommonJS version for security updates 😃

I ran into the same problem today.

I was also using the node-fetch package whose authors made the same mistake as nanoid: their current major version is ESM-only. Almost two years later since this change and their “old” CJS release is still downloaded 25 times more frequently than their current ESM-only release (you can check NPM stats).

I wish package authors would understand that people can’t switch to ESM because this would mean breaking the vast majority of their current dependencies. Switching popular packages to ESM-only will end up causing pain to others for 5 years or so and with the shiny new bleeding-edge version being barely used. So a lose-lose situation.

The final solution to this kind of issue will probably be solved in the Javascript standard which must provide a compatible upgrade path without these showstopper compatibility issues.

this is terrible, any alternatives to this lib, not doing such bullshit? Why do good libraries like husky and this one always have to fuck it up somehow?

I’m having the same issue in two flavors. first one was described above. second one is:

 Details:

    /home/circleci/project/node_modules/nanoid/index.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,jest){import { randomFillSync } from 'crypto'
                                                                                      ^^^^^^

    SyntaxError: Cannot use import statement outside a module

    > 1 | import { customAlphabet } from 'nanoid';
        | ^
      2 |
      3 | const letters = customAlphabet('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ', 1);
      4 | const alphanumeric = customAlphabet('0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ', 5);

in short, I need to turn on an experimental feature in node to enable ESModules import in Jest. I can’t wait for ESModules to become a standard, but right now it’s not yet frictionless.

this is my update PR: starwards/starwards#847

Joining the party late, after much reading to make this work in a pretty large NestJS production project we have just migrated, I’ve installed version 3.3.5 and it works like a charm. Thanks @ai for your patience on some of the not-so-nice comments I’ve been seeing.

To all, its an open source project and let’s just be thankful that the maintainer does what he can for OSS. If something doesn’t fit well in your apps, just fork and apply the changes you see fit. I don’t think its fair to resort to bashing.

Cheers 🖖

The only downside is node_modules being slightly bigger.

The downside is maintaince from the repository owner.

I do not have enough funding from my open source to spend extra time for both ESM and CJS versions.

Why do good libraries like husky and this one always have to fuck it up somehow?

Because moving to ESM is a global trend in JS ecosystem. It is better to join it.

… since I literally can’t import the latest I’m just gonna keep using shortid.

“We will support 3.x branch with CommonJS for users who can’t migrate to ESM”

https://github.com/ai/nanoid/blob/main/CHANGELOG.md#40

Use this version while the author fixes commonjs issue:

npm i -S nanoid@^3.0.0

Thank you, it’s works for me

@sugoidesune it is in Install section of docs

https://github.com/ai/nanoid#install

Use this version while the author fixes commonjs issue:

npm i -S nanoid@^3.0.0

struggling to convert to ESM, I get random error, finding on StackOverflow nothing work. End up using

yarn add nanoid@3.3.4

I wish I could find some projects that use expressjs typescript with ESM module. Maybe 4.x just for client-side example React app

I personally would have no problem with libraries pushing users to ESM if nodejs & electron were ready for it

Electron and Node.js will not be ready for years if there will not be push from the community.

It is better to support ESM issues in Electron and Node.js.

Im perfectly happy to keep using v3 until I can switch things to ESM

You do not need to always use the latest version of the dependency. You need to use the latest supported version. Both branches 3.x and 4.x are supported. Don’t worry that you are on 3.x branch.

@pBread just move your project on ESM. You will have problems with CJS project not only because of Nano ID, but because of all Sandre’s packages, etc. Even Vite deprecated CJS API.

Open source is about community work, not about demanding something from people whom you are not paying.

Some funny stats from npmjs:

nanoid weekly downloads: 37 million.

v4 and v5 combined combined weekly downloads (ESM): 1.9 million. v3 weekly downloads (CJS): the rest up to 37 million.

“ESM is the future”. Ok, but how many centuries into the future ? 😃

In my case, I just needed to generated a random code. So I just did this instead:

const crypto = require('crypto');

function generateRandomCode(length, characterSet) {
  let code = '';
  for (let i = 0; i < length; i++) {
    const randomIndex = crypto.randomBytes(1)[0] % characterSet.length;
    code += characterSet[randomIndex];
  }
  return code;
}

// Example usage:
const characterSet = '349ACEFHKLMNPRTWXY';
const codeLength = 5;
const randomCode = generateRandomCode(codeLength, characterSet);
console.log(randomCode); // prints a random code of length 5

@bkniffler what’s even easier is just using nanoid@3

Alrighty, I’ll fork my own version.

@pBread are you forking nanoid? 3.3.7 was released not too long ago… 3.x is still fine if you need CJS, and don’t want to for whatever reason move to ESM.

…

@ai I admire that you still have the strength to write everyone back 😅

I’m impressed as @jsardev is. So incredibly patient.

@vdjurdjevic if you like to keep everything fresh, you have an another reason to move to ESM. ESM is the future of imports in JS. Keep your project fresh too. 😊

Things will only have a chance of moving to ESM when nodejs starts enforcing it (which might as well be eternity), until then there’s just not enough pressure to do it. Nobody is going to try and update/replace countless mini-libraries down the depedency chain just because of some developer activism. And that’s all this is. Everyone has the right to publish open source libraries that output to only ESM or not, but CJS is here to stay and that’s the reality.

To those who really don’t want to use v3, you have two options:

• Import v4 using a library that is able to import ESM libraries (yes, they exist)
• If you’re not going to spam it in your project, just paste this code https://github.com/ai/nanoid/blob/main/nanoid.js

I don’t want to worry about being stuck on an obsolete version which will not be supported soon.

Nano ID 3 is not obsolete. It is a parallel version. We will support it for a few years.

Just use Nano ID 3.x. There are no rational problems with this version.

Or is there a better alternative for Jest that has better ESM support?

For simple Node.js libraries uvu is better.

For React projects Vitest is the best option.

For people coming here because of Jest specifically you can setup a mock for nanoid which worked to solve our issues: mock.js

jest.mock('nanoid', () => {
  return { nanoid: () => '1234' };
});

and then call it in global setup: jest.config.js

{
  ...
  setupFiles:["./mock.js"]
};

lol, this thread keeps going. @ai I admire that you still have the strength to write everyone back 😅

thats worked for me : npm uninstall nanoid npm install nanoid@3.3.4

@eezing this is why I moved from Jest

Use 3.3.4 if you need CommonJS support. Use 4.0.0 if you need ESM support.

Removed CommonJS support. Nano ID 4 will work only with ESM applications. We will support 3.x branch with CommonJS for users who can’t migrate to ESM.

See: https://github.com/ai/nanoid/blob/main/CHANGELOG.md#40

I was using this library for educational purposes to generate random IDs for a simple file-based database. Not anymore, I guess. I will just move to crypto.randomUUID() which is already built into Node.js.

same here

And if you keep esm by default but allow to explicitly import from nanoid/cjs?

Maintaince cost will be again too big (for the feedback I have from the community).

This ESM/CJS nonsense is such a mess… how did they honestly not build interop into the spec, it’s just causing pain and suffering for all involved.

I’ll look into sticking with 3.x, its a great library and I’m sticking with it either way 😃

No, I’m going to use v4 using the ‘hacky and dangerous’ method because I don’t want to worry about being stuck on an obsolete version which will not be supported soon.

Also see the author’s feedback in this previously-closed issue: https://github.com/ai/nanoid/issues/364#issuecomment-1150173952

same issue

@ai I find your reasoning for not dual publishing unconvincing.

Export maps are part of the esm transition so your exact same reasoning for pushing esm and forcing the ecosystem to migrate applies there too. They are also far more supported than just plain old esm.

esbuild takes like some 10ms to build twice. And there’s tons of tools to use node register with that are trivial to use if you somehow are forced to import just esm.

And any analyzer worth its weight will need to support export maps to do so.

I’ve gone the dual publishing route and had no complains from tons of users so far. If you do it properly it supports both without and hiccups across all sorts of tools. And you avoid giant threads like this on your project.

The only downside is node_modules being slightly bigger.

this is terrible, any alternatives to this lib, not doing such bullshit? Why do good libraries like husky and this one always have to fuck it up somehow?

agreed, this whole shift is zero benefit if you’re typescript anyway and endless pain.

I use cuid on another react native project. I think it might have some similar ESM bs issues tho https://www.npmjs.com/package/cuid

Are you aware that all packages dependent on your library are forced to adapt (right here, right now)? Isn’t it better to add a build task that also generates the common js before publishing to npm?

@ai would you consider releasing an npm module called something likm nanoid-v3 or nanoid-cjs which tracks v3?

I only ask because I am a regular user of tools like yarn upgrade-interactive. It’s going to constantly tell me that I can upgrade nanoid with the current approach

Yes, I’m one of those people that likes to keep everything at cutting edge

ESM is a disaster in typescript. so many projects have issues like this, eg node-fetch and others. for plain JS it’s possible to convert over, but TS support is really patchy esp when you have modules inside other modules.

just hope nobody is using nano in another package as it will suddenly blow up

Just downgrade the package, it will work fine yarn add nanoid@3.3.4

Reverting back to 3.* works, however, I always update my packages to the latest version, and don’t want to keep this one outdated. You can import the package using dynamic import and it works for version 4.0.0. Put this code in constructor or as part of your app’s initialization.

  (async () => {
      const module = await (eval(`import('nanoid')`) as Promise<any>);
      const nanoid = module?.nanoid;
     console.log(nanoid && nanoid(10));
    })();

If you’re coming here from React, v18 shipped the useId hook that might work for you.

After all the time wasted chasing this, and after taking steps to attempt to warn all our developers that this library (and in our case, ONLY this library) can never be updated, you’re right. It was pretty easy typing in a different version number. Of course, difficulty in rolling back was never the complaint.

Attempting to change the module system (compilerOptions.module) from CommonJS to ESNext in tsconfig.json. doesn’t work in Node.

It now appears all Node users will have to BOTH manually roll back to v3.3.4 AND begin looking for a replacement for this library as CommonJS has been permanently abandoned in v4.

Too bad it’s so easy to accidentally or silently upgrade nano versions and break your entire build, as I did.

no the best way is to use a less dogmatic package, esp if you’re using TS, until the TS flow is a bit smoother.

for a greenfield JS project, starting with ESM is an option.

If a version of an open source node library has got an end of life announced for it

There is no EOL announced for Nano ID 3.x.

For now, I am planning to support it util most of CJS users will use it.

it’s about understanding the reality of many projects out there that do not have the resources or priorities around upgrading to ESM

You need to understand the complexity of dual CJS/ESM support. As a developer of dual-publish I found the true reality of how hard it is to support all edge cases just tried to support all of them.

You should be able to wrap this with a dynamic import:

For example:

src/lib/nanoid.ts

import type NanoidLib from 'nanoid';

let _lib: typeof NanoidLib;

/**
 * Wrapper to import the ESM module into this project
 *
 */
export async function nanoid(size?: number) {
  // Load library
  if (!_lib) {
    _lib = await import('nanoid');
  }

  // Create ID
  return _lib.nanoid(size);
}

src/usage.ts

import { nanoid } from 'lib/nanoid';
async function doingStuff() {
  const id = nanoid();
}

@vdjurdjevic if you like to keep everything fresh, you have an another reason to move to ESM. ESM is the future of imports in JS. Keep your project fresh too. 😊

I admire the attempted prescience but please stop making these decisions for developers that take pride in their work. We will decide the future of our own stack whether it includes this dep or not.

Trust me I tried 😃 But everything started to break, spent few hours trying to make it work and then decided to go back. It’s medium size project, with 70 dependencies, it’s not that easy to switch

I was using this library for educational purposes to generate random IDs for a simple file-based database. Not anymore, I guess. I will just move to crypto.randomUUID() which is already built into Node.js.

Basically, I did the same as built-in would make more sense since may be a little more supportive.

I have the same problem. I want to use the latest version available but it doesn’t work 😕

For pnpm users who frequently use pnpm update --latest, they just added a configuration option for pnpm.updateConfig.ignoreDependencies in v7.13.0:

pnpm add nanoid@3

// package.json
{
  "pnpm": {
    "updateConfig": {
      "ignoreDependencies": ["nanoid"]
    }
  }
}

Something like tsup or just a small script that runs esbuild twice typically works and can be added as a pre publish or commit hook.

Just run esbuild will not work.

I created dual-publish and just check how many edge cases maintainer have to think about (Node, webpack, Node + TS, webpack + ts, esbuild, rollup, Parcel).

Maintaining cost is not when everything is working, but when it goes to edge cases.

It’s a little painful, every time I need to update packages with npm-check-updates, I have to downgrade nanoid to version 3.X.X. I’ve already tried to migrate the project I’m working on to ESM, but many packages don’t support it yet, too many errors that I don’t think I can handle.

With npm-check-updates, you can use -x option to exclude some dependency from the update, instead of updating then downgrading. For example to exclude nanoid:

ncu -u -x nanoid

It’s a little painful, every time I need to update packages with npm-check-updates, I have to downgrade nanoid to version 3.X.X. I’ve already tried to migrate the project I’m working on to ESM, but many packages don’t support it yet, too many errors that I don’t think I can handle.

Current state of ecosystem when we need to support both ESM and CJS is very hard for maintainers.

That is true, but esm only packages can be very hard for users 😉

Im perfectly happy to keep using v3 until I can switch things to ESM (there is already a pretty long list of other dependencies that cant be updated), but that switch is currently impossible due to electron not supporting ESM in the backend at all, and jest needing nodejs to finish some features before they can have feature parity with CJS. I personally would have no problem with libraries pushing users to ESM if nodejs & electron were ready for it. But they aren’t, so even though ESM has been around for years, the push from library authors feels premature to me.