Webpack Build Failure Due to Missing Extensions in @deck.gl-community/editable-layers

[maslunde]

Hello,

I am encountering a problem with the @deck.gl-community/editable-layers package. Specifically, Webpack fails to resolve certain modules due to missing file extensions. This issue is causing build errors in my project.

Error Details:

When attempting to import from @deck.gl-community/editable-layers, I receive the following error:

ERROR in ./node_modules/@deck.gl-community/editable-layers/dist/index.js 64:0-54
Module not found: Error: Can't resolve './utils/memoize' in 'C:\dev\map\node_modules\@deck.gl-community\editable-layers\dist'
Did you mean 'memoize.js'?
BREAKING CHANGE: The request './utils/memoize' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

Steps to Reproduce:

Install the @deck.gl-community/editable-layers package.

Import modules from @deck.gl-community/editable-layers in a Webpack project:
import { EditableGeoJsonLayer, DrawPolygonMode, ViewMode, ModifyMode } from '@deck.gl-community/editable-layers';

Run Webpack build.

Expected Behavior:

Modules should be resolved correctly without requiring explicit file extensions in import paths.

Actual Behavior:

Webpack fails to resolve the module due to missing file extensions, resulting in build errors.

Proposed Solution:

The issue seems to be related to the ES module specification, which requires explicit file extensions. Here are some suggestions to address the issue:

Update Import Paths: Ensure all internal import statements in the package include file extensions. For example:

import { memoize as _memoize } from './utils/memoize.js';

Package Updates: If this is a known issue, releasing an updated version with the necessary fixes would be appreciated.

Node.js and Webpack Versions:
Node.js: 20.14.0
Webpack: 5.93.0

Thank you for your assistance. Please let me know if you need any more information or if there are any workarounds available.

Best regards,

Martin

[ibgreen]

@maslunde Thanks for reporting.

The issue seems to be related to the ES module specification, which requires explicit file extensions. Here are some suggestions to address the issue:

I doubt that the lack of .js extensions in the source is the actual root cause here, because the addition of file extensions in import statements are handled by the build process in ocular-dev-tools for all vis.gl repos and we never import with explicit extensions in our source code.

[ibgreen]

My apologies, I will ask you to move general help requests like this to the Discussions tab. Issues are for actionable, well-defined bugs. I have updated the github issue template to explain this so you don't have to file your issue twice in the future.

Once we narrow down the root cause, we file an issue.

[maslunde]

Thanks for your fast reply, @ibgreen. I can see another user with more or less the same issue: #118. It's the only package I have installed complaining about this. Bug or not, hope you find out. I'll try to investigate more on my side as well.

[maslunde]

Found a solution and it was connected to webpack.

In Webpack 5, a new behavior was introduced where the resolve.fullySpecified option affects how module resolution is handled. By default, Webpack expects file extensions to be specified explicitly in import statements. This can cause issues with certain packages or module structures that do not include the file extensions in their imports.

With this I updated webpack config with this and it works.

rules: [
        {
          test: /\.(js)$/,
          resolve: {
            fullySpecified: false, // disable the behavior
          },
        },
        ... other rules
 ]

I'm not 100% sure, but I think this config would be unnecessary if your package had been explicit with the file extensions in the exports. Webpack 5 introduced stricter handling of module resolution to enforce explicit file extensions, aligning with the ECMAScript module specification.

I have made some libs and are always explicit with the file extensions on the exports.

[ibgreen]

@maslunde Yes, you were right and I was wrong: #121 - our build tools do handle this but this repo is relatively new and wasn't properly configured.

[maslunde]

Ah, shit happens. Good we found out :) Cheers

[ibgreen]

Landed, pending #126

[ibgreen]

Published in v9.0.3, sorry for the long delay