v4 can't be imported in node

Question

v4 can't be imported in node

g012 opened this issue 3 years ago · 124 comments

Hello,

I'm not knowledgeable at all in all the module formats / import mess of javascript / node, but I'm using KeystoneJS and I import nanoid in it. Since version 4 (2 days ago), I have this error :

Error [ERR_REQUIRE_ESM]: require() of ES Module /node_modules/nanoid/async/index.js from schema.ts not supported. Instead change the require of index.js in schema.ts to a dynamic import() which is available in all CommonJS modules.

This is how I've always imported nanoid :

import { nanoid } from 'nanoid/async';

Reverting to 3.3.4 works.
I see in the commit comment that you removed CJS support, but as I understand, using this import statement, I'm using the new thingy module stuff, not CJS which uses require instead, and you have "type: module" in your package.json, so I really don't know what's wrong here.

Any idea what I'm doing wrong ? Thanks !

marekkobida commented 3 years ago

Me too.

amiralitaheri-it commented 2 years ago

same here

👎4

conqr2 commented 2 years ago

💩

👍13
👎6

Answer 1 · 2022-06-09T12:09:36.000Z

I'm also having this issue

Answer 2 · 2022-06-09T12:48:49.000Z

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

Answer 3 · 2022-06-09T12:49:25.000Z

Also see the author's feedback in this previously-closed issue: #364 (comment)

Answer 4 · 2022-06-09T12:52:56.000Z

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).

Answer 5 · 2022-06-09T13:39:53.000Z

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

This doesn't help at all, we saw the comment in the commit on main page of code repo, as stated.

Also see the author's feedback in this previously-closed issue: #364 (comment)

In this one the guy says he was using require, and is told to move to import. As stated, I (we ?) are already using import since long.

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).

Thanks, I've tried changing module: "commonjs" to module: "esnext", but it made no difference. Could you share your whole tsconfig file ? Here's mine:

  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "jsx": "react"
  }
}

Answer 6 · 2022-06-09T13:56:09.000Z

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

Answer 7 · 2022-06-09T15:45:30.000Z

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.

:)

Answer 8 · 2022-06-13T15:29:07.000Z

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

Answer 9 · 2022-06-16T16:43:29.000Z

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.

Answer 10 · 2022-06-16T16:48:18.000Z

. 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

Answer 11 · 2022-06-17T06:54:45.000Z

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.

:)

Hi Daniel,

Yes I think you're right, the Keystone JS toolset converts typescript to CJS, and if I disable that, I get lint warnings for k6 core and some others, so I've decided to stick with branch 3 until everything migrates.

Thanks for the help !

Answer 12 · 2022-06-22T21:39:13.000Z

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!

Answer 13 · 2022-06-22T21:43:24.000Z

... 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

Answer 14 · 2022-06-26T01:50:22.000Z

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

Answer 15 · 2022-06-26T09:48:15.000Z

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.

Answer 16 · 2022-06-27T08:57:05.000Z

Use this version while the author fixes commonjs issue:

npm i -S nanoid@^3.0.0

Answer 17 · 2022-06-28T15:14:59.000Z

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

Answer 18 · 2022-06-28T15:23:08.000Z

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.

You need to duplicate every file in npm package which increase node_modules size.
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).
Dual packages requires extra build step (like dual-publish or babel). With ESM-only you can publish your repository directly.
It also make more complex another tools. For instance, Size Limit will require extra plugin.
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.

Answer 19 · 2022-06-29T13:55:30.000Z

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.

Answer 20 · 2022-06-29T13:59:15.000Z

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.

Answer 21 · 2022-06-29T16:39:29.000Z

I don't really mind maintainers of packages switching to ESM. It's their project. Only I wish they don't forget their old CommonJS packages when vulnerabilities in dependencies or similar occur. So I was glad to hear this is the case for this super useful package :)

I really need to find out how I can get ESM modules working with Jest. Or is there a better alternative for Jest that has better ESM support? Anyone tried Vitest? Looks like its compatible with Jest's expect?

Answer 22 · 2022-06-29T16:45:57.000Z

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.

Answer 23 · 2022-06-29T16:50:51.000Z

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.

Exactly. Im using 4.x in some projects and 3.x in others, depending on whether they are ESM or not. Hopefully 3.x will get updates for a few years, as I expect ESM wont be usable for everyone for at least a couple more years

I really need to find out how I can get ESM modules working with Jest. Or is there a better alternative for Jest that has better ESM support? Anyone tried Vitest? Looks like its compatible with Jest's expect?

I believe that Jest does mostly work, but they don't have feature parity with CJS. jestjs/jest#9430
The main blocker for me is the lack of mock support, which I believe is blocked on the required nodejs features still being experimental.

Answer 24 · 2022-07-08T10:13:09.000Z

Use this version while the author fixes commonjs issue:
npm i -S nanoid@^3.0.0

Thank you, it's works for me

Answer 25 · 2022-07-11T13:35:21.000Z

Just stay on Nano ID 3 if you have CJS project. We will support Nano ID 3 for a few years.

I delete a very hacky and dangerous advice of crazy wraps to load ESM to CJS.

Answer 26 · 2022-07-11T14:12:56.000Z

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.

Answer 27 · 2022-07-11T14:15:27.000Z

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.

Answer 28 · 2022-07-11T14:22:42.000Z

If a version of an open source node library has got an end of life announced for it, I consider it already on its way out. It's how I and many other devs out there work, and it's all about minimising technical debt.

That will be the only dependency of over 50 in my package.json I have to worry about pinning, which I've managed to avert worrying about by doing this 'super dangerous hack' (which isn't really that dangerous at all, I have an integration test that covers usage of it and continuously audit my packages).

The problem here isn't whether or not people should stay on v3 or not, it's about understanding the reality of many projects out there that do not have the resources or priorities around upgrading to ESM. ESM isn't a magical solution to dependency security, you can still do plenty of mischief whether your lib is used in CJS or ESM mode.

Answer 29 · 2022-07-11T14:27:46.000Z

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.

Answer 30 · 2022-07-11T14:32:51.000Z

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 :)

Answer 31 · 2022-07-12T00:11:04.000Z

Personally, I don’t have problems with ESM. I have been struggling to get libraries like got, react-markdown to work in Jest test files. That’s my main blocker for the switch. And now with the memory issue in latest Node 16 and/or Jest 28 it’s a struggle to upgrade to newer versions :(

Answer 32 · 2022-07-19T11:08:17.000Z

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

Answer 33 · 2022-07-23T20:42:42.000Z

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

Answer 34 · 2022-08-06T18:20:38.000Z

Hi! Have the same issue. I just change the version nanoid. version 3.0.0 instead of version 4.0.0 in package.json file.

Answer 35 · 2022-08-16T08:20:21.000Z

Could you try with this configuration in tsconfig complierOptions?

"target": "es2020", "module": "es2020"

Answer 36 · 2022-08-18T08:05:41.000Z

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

Answer 37 · 2022-08-20T06:44:14.000Z

Good library, unfortunate release decision.. here I join the v3 gang.

Answer 38 · 2022-08-21T22:31:35.000Z

I'm trying to use nanoid with TypeScript on nodejs and getting this error.

const nanoid_1 = require("nanoid");
                 ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /opt/xxapi/node_modules/nanoid/index.js from /opt/xxapi/dist/controllers/auth/signup.js not supported.
Instead change the require of index.js in /opt/xxapi/dist/controllers/auth/signup.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/opt/xxapi/dist/controllers/auth/signup.js:25:18)
    at Object.<anonymous> (/opt/xxapi/dist/routes/auth.js:12:18)
    at Object.<anonymous> (/opt/xxapi/dist/index.js:7:32) {
  code: 'ERR_REQUIRE_ESM'
}

Node.js v18.7.0

Answer 39 · 2022-08-21T22:39:31.000Z

@bootrino you need to use pure ESM app in TS ("module": "esnext") to use Nano ID 4.

If you still convert TS app to CJS, use Nano ID 3.

Answer 40 · 2022-08-22T01:19:03.000Z

OK, although I shouldn't need to reconfigure TypeScript to use a library.

Answer 41 · 2022-08-23T01:59:11.000Z

@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

Answer 42 · 2022-08-23T02:03:03.000Z

It's going to constantly tell me that I can upgrade nanoid with the current approach

I have the same problem on my CJS projects (like PostCSS). I think we should not try to update always on latest version (or go to ESM if we want the latest solution).

Answer 43 · 2022-08-24T10:38:40.000Z

Very strange. Is the only way to fix this downgrading to v3? I will do that for now.

Answer 44 · 2022-08-24T10:43:33.000Z

Is the only way to fix this downgrading to v3?

No. The best way is to move project to ESM.

If you use TS it means “true ESM” with "module": "esnext".

Answer 45 · 2022-08-24T11:16:33.000Z

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.

Answer 46 · 2022-08-24T13:18:26.000Z

@ai Apologies, I don't really know what this means. I add new packages all the time, and this never seems to happen. We are using TS, but we have a project set up in a certain way, so unfortunately, we can't just 'move the project to ESM'. v3 works fine for me for now. Thanks

Answer 47 · 2022-08-24T13:35:10.000Z

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.

Answer 48 · 2022-08-26T21:52:16.000Z

thanks got not only me

Answer 49 · 2022-08-31T11:18:27.000Z

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

Answer 50 · 2022-09-04T19:09:27.000Z

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.

Answer 51 · 2022-09-04T19:15:49.000Z

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

Luckily its just as easy to rollback to v3 and stick with that

Answer 52 · 2022-09-07T21:46:35.000Z

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.

Answer 53 · 2022-09-23T08:14:07.000Z

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?

Answer 54 · 2022-09-23T10:07:23.000Z

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.

Answer 55 · 2022-09-23T10:50:17.000Z

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?

Answer 56 · 2022-09-23T10:51:48.000Z

Isn't it better to add a build task that also generates the common js before publishing to npm?

We have it for 3.x release, and it took a lot of time to maintain and have problem for some edge cases.

Answer 57 · 2022-09-23T13:42:23.000Z

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

Answer 58 · 2022-09-24T18:39:41.000Z

@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.

Answer 59 · 2022-09-24T18:44:32.000Z

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.

Answer 60 · 2022-09-25T03:28:19.000Z

Fair. Not critiquing just thought I’d add perspective as someone doing it. 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.

Answer 61 · 2022-09-25T04:45:19.000Z

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

This isn't true, unless you explicitly specify the dependency version as *.

Answer 62 · 2022-09-25T09:31:41.000Z

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.

Answer 63 · 2022-09-27T10:52:59.000Z

And if you keep esm by default but allow to explicitly import from nanoid/cjs? At least I'd be able to alias in that case. Using nanoid in most cases works ok, but setting up jest to allow for certain packages to use esm is a pita in monorepos. Setting up an alias is much easier.

Answer 64 · 2022-09-27T12:31:48.000Z

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

Answer 65 · 2022-09-27T14:02:21.000Z

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).

Answer 66 · 2022-10-04T17:37:21.000Z

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"]
    }
  }
}

Answer 67 · 2022-10-05T00:58:06.000Z

@michaelhays it’s nice that this exists, but this probably ignores 3.x releases as well. I doubt there’s much that can go catastrophically wrong in nanoid, but it’s something one should be aware of.

Answer 68 · 2022-10-05T02:43:22.000Z

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

Answer 69 · 2022-10-09T23:06:51.000Z

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.

Answer 70 · 2022-10-12T00:06:56.000Z

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.

Would you like me to create a PR with the build script for both ESM and CJS versions?

Answer 71 · 2022-10-12T00:10:06.000Z

Would you like me to create a PR with the build script for both ESM and CJS versions?

PR is not help. It will take me a week to then fix all possible issues and then I will spend a day every week answering people with rare Jest edge case.

I already wrote dual-publish build script (it is not so easy btw) but in some moment I found that it is just impossible to cover all edge cases.

Answer 72 · 2022-10-20T18:11:03.000Z

nanoid and express are my favorite packages of all time.

If this arm-chair comment is not useful, please excuse me. Possibly the build process could be simplified to enable cjs and esm. As mentioned here, If nanoid exports a single default, a cjs variant can be generated with sed.

cp nanoid.js nanoid.cjs && sed -i 's/export default/module.exports =/' nanoid.cjs

After form-urlencoded began using this approach, cjs/esm issues went away.

In the previous ticket, you did not want to try this approach because of risks. Since risks are already incurred, maybe the approach could be reconsidered.

Answer 73 · 2022-10-28T08:18:54.000Z

same issue

Answer 74 · 2022-11-08T12:03:56.000Z

I have the same problem. I want to use the latest version available but it doesn't work :/

Answer 75 · 2022-11-15T09:45:26.000Z

downgrading to version 3.3.4 worked for me, if it can help

Answer 76 · 2022-11-16T08:24:32.000Z

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.

Answer 77 · 2022-12-06T08:18:23.000Z

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.

Answer 78 · 2022-12-06T09:24:11.000Z

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 🙄

Answer 79 · 2022-12-21T02:28:38.000Z

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));
    })();

Answer 80 · 2022-12-24T00:05:37.000Z

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

Answer 81 · 2022-12-28T02:40:23.000Z

the same problem in sequelize seeder esm script, try to use follow replace it.

import { v4 as uuid } from 'uuid'
const nanoid = (size) => {
  return uuid().replace(/-/g, '').slice(0, size)
}

Answer 82 · 2023-01-13T09:41:21.000Z

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.

Answer 83 · 2023-01-29T10:10:44.000Z

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

Answer 84 · 2023-01-31T21:53:12.000Z

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.

Answer 85 · 2023-02-07T06:57:18.000Z

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

You need to duplicate every file in npm package which increase node_modules size.

Since the files are only on the file system, I don't see this as a problem, since when bundling with webpack, rollup etc for a nuxt, next, svelte, ... app only the corresponding module file ( cjs or esm ) is included in the bundle.

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).

Yes, Jest causes problems more often, but I think you can take that into account before you start backporting changes.

Dual packages requires extra build step (like dual-publish or babel). With ESM-only you can publish your repository directly.

But cjs, can be used in both a cjs and esm ecosystem. This is not the case with esm for top level imports.

It also make more complex another tools. For instance, Size Limit will require extra plugin.

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.

True

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.

You are absolutely right, but I think the step, one should go only if e.g. NodeJs Esm no longer runs in expermintal mode.

Answer 86 · 2023-02-07T07:10:23.000Z

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

Answer 87 · 2023-02-07T07:53:28.000Z

@jpike88 I see it exactly the same way

Answer 88 · 2023-02-07T10:05:19.000Z

But cjs, can be used in both a cjs and esm ecosystem. This is not the case with esm for top level imports.

CJS can’t be used as module from URL:

import { nanoid } from 'https://cdn.jsdelivr.net/npm/nanoid/nanoid.js'

Also CJS has problems with named exports in some environments.

Answer 89 · 2023-02-12T03:02:21.000Z

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.

Answer 90 · 2023-02-28T20:45:14.000Z

This should be front page on the readme because this is wasting a lot of peoples time.

Answer 91 · 2023-02-28T20:46:19.000Z

@sugoidesune it is in Install section of docs

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

Answer 92 · 2023-03-12T16:51:10.000Z

@ai Thanks for choosing to support CommonJS in v3.

I tried converting a monorepo to ESM; builds and runs fine, but Jest blew up. No dice for now.

Answer 93 · 2023-03-12T18:49:50.000Z

@eezing this is why I moved from Jest

Answer 94 · 2023-03-14T02:28:19.000Z

@ai what did you move to? is there some other testing framework that works with nanoid ?

Answer 95 · 2023-03-17T21:22:27.000Z

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

Answer 96 · 2023-03-24T00:14:20.000Z

@dcsan not ai, but want to share this opinion after using different test frameworks,

for small applications using latest version of node: use node's native test runner, node:test,
~~for everything else: use ava.~~ use node:test for everything -- recent versions of node:test perform as well at least as well as ava

Answer 97 · 2023-05-14T11:30:05.000Z

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!

@garretthogan you should amend your comment, knowing that v3 will continue to support CommonJS, and v4 was clearly indicated to support only ESM.

Thank you @ai for supporting both!