MilSymbol 2.2.0 breaks NextJS build since 2.0.0

[JLunda]

My project has a dependency of ^2.0.0 on milsymbol's NPM package, and uses NextJS for page compilation. Fixing the version to 2.0.0 allows for a successful build, but allowing ^2.0.0, which pulls version 2.2.0 of the package breaks the NextJS build with the following error:

Thank you for all the work that you do on this package. It is much appreciated!

[spatialillusions]

This is probably since we now expose milsymbol as a proper module in the package.json. This makes it behave like it should when you are using imports.

You can probably get some help from this. https://flaviocopes.com/fix-cannot-use-import-outside-module/

Otherwise, provide a minimal build example and provide as much information as possible about what in milsymbol you think causes this error. The changes between 2.0.0 and 2.2.0 are really minimal, so I really think it is a build system thing on your end that is causing the error.

[kjellmf]

I ran into a similar issue with MilSymbol 2.2.0 and vitepress. I did not had time to investigate back then and had to add a temporary workaround in my vite build file:

vite: {
    ssr: {
      noExternal: ["milsymbol"],
    },
  },

https://github.com/orbat-mapper/orbat-mapper/commit/89263064fae9cbbbd4aa87747eb4a14aa03d047a

My hunch is that the problem is related to a missing entry in the package.json file of milsymbol, but I'm not sure.

[spatialillusions]

As far as I know, the only change except for version numbers between package.json 2.0.0 and 2.2.0 was that the row:

"exports": "./index.js",

was added. This was done to make sure that you could import milsymbol as a pure es6 module. I know that it solved things when building with rollup, but it is possible that it made other things break.

If you are able to track down the problem and can recommend a solution, please let me know.

[kjellmf]

Trying to understand the correct module configuration for package.json gives me a headache :) I've tried to compare your package.json file with one I use from a template:

  "type": "module",
  "main": "./dist/convert-symbology.umd.cjs",
  "module": "./dist/convert-symbology.js",
  "exports": {
    ".": {
      "import": "./dist/convert-symbology.js",
      "require": "./dist/convert-symbology.cjs"
    }
  },
  "types": "./dist/convert-symbology.d.ts", 

The only difference is the type and module entry. I don't think you need the "module" entry anymore. Maybe adding "type": "module" will help, but I'm not sure. I'm not able to test this at the moment.

[ogarcia-akk]

I have also ran into a similar issue where the Type: Symbol was not being properly imported. Fixing the version to 2.0.0 has fixed it. After doing some reading while trying to figure out what the problem was, I came up with a comment in a StackOverflow issue that says that equally named files that only differ in the d.ts/.ts extension don't get recognized for exporting. This seems to be the problem, considering that the export file is named index.ts and the types file is named inxed.d.ts in the project.

Here is the source from the issue I'm talking about. Issue

Hope this helps in some way.

[jj0b]

Just a note that I had the same issue as @JLunda when trying to use milsymbol in a Next.js app. Changing to 2.0.0 fixed the problem.

[shellwhale]

I'm using Svelte along with it and I am adding "type": "module" to node_modules/milsymbol/package.json to prevent that error. @spatialillusions is there a reason why it's not by default in the package.json ?

[carlocorradini]

For a temporary solution see https://github.com/spatialillusions/milsymbol/issues/299#issuecomment-2396202156