"Failed to parse source map" errors

[israel-hdez]

When using micro-memoize version 4.0.10 in a react application, starting the application in development mode is giving the following warnings:

Failed to parse source map from '/home/user/Projects/cra-app/node_modules/src/Cache.ts' file: Error: ENOENT: no such file or directory, open '/home/user/Projects/cra-app/node_modules/src/Cache.ts'                                                            
                                             
Failed to parse source map from '/home/user/Projects/cra-app/node_modules/src/index.ts' file: Error: ENOENT: no such file or directory, open '/home/user/Projects/cra-app/node_modules/src/index.ts'                                                                                  
                                                                                         
Failed to parse source map from '/home/user/Projects/cra-app/node_modules/src/utils.ts' file: Error: ENOENT: no such file or directory, open '/home/user/Projects/cra-app/node_modules/src/utils.ts'

which then leads to some warning in following lines in the console.

Indeed, after looking at the contents of the .map files in the package of version 4.0.10 the files are referencing two paths up, which leads to trying to look at a path outside the package:

$ cat node_modules/micro-memoize/dist/micro-memoize.js.map
{"version":3,"file":"micro-memoize.js","sources":["../../src/utils.ts","../../src/Cache.ts","../../src/index.ts"],"sourcesContent":[null,null,null],"names":[],"mapping
[...truncated...]

This is happening with latest version 4.0.10. Probably, somehow, the source map files were badly generated because the previous patch version 4.0.9 does not generate these warnings. I have reverted as a workaround.

[Bessonov]

Just fixed this issue with my own module. Now, the micro-memoize is the only module which produces this error.

[planttheidea]

Apologies for the delay in getting this resolved, life has been pretty wild the last couple of months. I have fixed this as-of version 4.0.11. Let me know if there are any more issues!

[landabaso]

I believe this is happening again as of 4.1.2:

node_modules/micro-memoize/dist/micro-memoize.js.map has references to src

[planttheidea]

@landabaso you are correct! Sorry about that ... reopening, and fixing posthaste.

EDIT: Actually ... there may be a misunderstanding of the issue at hand here, and my response was jumping the gun based on the same misunderstanding from my own fallible memory 😅 .

The issue is not that src files are referenced in the map files, but rather that the files referenced were not in the correct location. If you look at the original post:

Indeed, after looking at the contents of the .map files in the package of version 4.0.10 the files are referencing two paths up, which leads to trying to look at a path outside the package:

The referenced locations in the original issue are:

{"version":3,"file":"micro-memoize.js","sources":["../../src/utils.ts","../../src/Cache.ts","../../src/index.ts"],"sourcesContent":[null,null,null],

However, since 4.0.11, the files reference the correct location which is only one folder up:

{"version":3,"file":"micro-memoize.cjs.js","sources":["../src/utils.ts","../src/Cache.ts","../src/index.ts"],"sourcesContent":[null,null,null],

Notice the ../ instead of ../../ prefix, which was putting the reference at the top of node_modules and experiencing relative access issues. I believe the issue wasn't that it was referencing files that don't exist, but just that it was referencing files that it was not allowed access to (outside the scope of the package).

That said, src files are no longer distributed as part of the package since 4.1.0, as part of this change which was a continuation of this request to produce less installation bloat. Based on the history in this thread, it seems like the lack of these reference files is not an issue (4.0.11 solved the issue with the removal of relative referencing to the top of node_modules, and that was even without the src files in the bundle).

Are you experiencing any specific issue? Or did you just notice src in the bundles and followed up? If you are experiencing a specific issue with the current setup I'd appreciate some repro steps (I do not see any issue when consuming the package, e.g. in moize which has it as a hard dependency), but if not then I'll close again.

[landabaso]

Hi @planttheidea , thanks for the reply and for maintaining this project. I'm getting same of errors as the OP. I use tsc to compile my sources. I installed parent project moize using npm install moize. Thanks and happy new year!

WARNING in ./node_modules/micro-memoize/dist/micro-memoize.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from './node_modules/micro-memoize/src/Cache.ts' file: Error: ENOENT: no such file or directory, open './node_modules/micro-memoize/src/Cache.ts'

WARNING in ./node_modules/micro-memoize/dist/micro-memoize.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from './node_modules/micro-memoize/src/index.ts' file: Error: ENOENT: no such file or directory, open './node_modules/micro-memoize/src/index.ts'

WARNING in ./node_modules/micro-memoize/dist/micro-memoize.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from './node_modules/micro-memoize/src/utils.ts' file: Error: ENOENT: no such file or directory, open './node_modules/micro-memoize/src/utils.ts'

[planttheidea]

Alright so there are a few options:

1. Restore the src files in publish, which will allow the maps to work as expected but increase download of the package in npm
2. Inline the source maps, which avoids publishing the source but has similar impact on download of package (and potentially bundle sizes)
3. Eliminate source maps entirely

The last point is controversial, and I found strong opinions on both sides when searching for other packages. Do you have an opinion on the topic? The files themselves are small, so I think option 1 is probably best, but it assumes there is value from the maps at all.

[planttheidea]

Quickly following up ...

I'm actively working on V5 (smaller, faster, more full-featured) and have decided to remove source maps in this update. I've done a lot of research on what other published packages do, and there is a strong argument that little benefit exists for providing them, as there is very little indirection to debug through in the bundled version and it provides little additional context for any issues resulting from breakages discovered. No timeline on V5 delivery, but I'll keep this open until then, at which point it should be resolved.

[unional]

Hi, I'm interested in learning about the arguments on sourcemap provide little benefits.

Do you found that because the gap between TS and modern JS are relative small (unlike in the old days where async/await are transpiled to generator with switch statement, for example), so debugging directly on JS is feasible? What about minified code?