Question about `Check that you are using the correct source map.`

[LouisSung]

Hi, not sure if this issue is belong to here, but I'll try to explain in detail and to see if anyone can help

• I'm using nrwl/nx to build an API service with nestjs/nest

  • And the following code is the built-in example provided by nx

• As mentioned in title, I face this error when generating treemap. I found out that --no-border-checks flag introduced in the newest release 2.4.2 can ignore the error and generate part of map.

  • Like this (almost 50% unmapped :o) (there are small ones not showing on the screenshot, please refer treemap.html below)

• However, I cannot find out which part is the unmapped part by tracing the source main.js and main.js.map

  • Here is my sourcemap code (thanks to source-map-visualization)
  • The error message is

    Your source map refers to generated column 44 on line 263, but the source only contains 43 column(s) on that line.
    Check that you are using the correct source map.

  • And the line 263 is (which has no column 44 indeed

    module.exports = require("@nestjs/common");

  • Here are my main.js, main.js.map, and treemap.html if needed (.txt is required for uploading to GitHub)

---

My questions are:

1. Is the unmapped part and the error happened because of that 3 external modules?

   I.e., webpack:/external "@nestjs/common", webpack:/external "@nestjs/core", and webpack:/external "tslib" as shown in my sourcemap link above

2. If those unmapped part is for the 3 external modules, how can I fix it (e.g., manually add them into treemap?)
   • E.g., using flags like --external-module=DIR_OR_MODULE_NAME can help on adding source map for external dependencies?

Thank you :D

[nikolay-borzov]

Hello,

1. Is the unmapped part and the error happened because of that 3 external modules? I.e., webpack:/external "@nestjs/common", webpack:/external "@nestjs/core", and webpack:/external "tslib" as shown in my sourcemap link above

Maybe. Unmapped bytes are usually generated code like webpack boilerplate, typescript helpers (tslib) and babel helpers. As you can see on source map visualization you've linked there are a substantial amount of unmapped code (code w/o highlighting)

2. If those unmapped part is for the 3 external modules, how can I fix it (e.g., manually add them into treemap?)

Unmapped bytes are not always indicate an error. I believe generated code isn't mapped intentionally - like why do you need mapping for webpack module loading code. If an external dependency is bundled it's in most cases get mapped

[LouisSung]

I believe generated code isn't mapped intentionally

All right Since I'm not familiar with source map, tslib, and webpack, that's why I wonder if this situation is acceptable.

I mean

1. If the --no-border-checks flag is introduced recently, how did the other people fix this error? (or it just seldom happened?)
2. Is the unmapped part ignorable? or I have to deal with (fix) it?
   • For example, Angular bundles have unmapped part too, but it won't exit as an error. As I know, unlike NestJS, Angular don't have runtime Node.js support; therefore, have to pack everything into its bundle
3. As of now, I have to use --no-border-checks to ignore that unmapped part so that whole process won't stop. Is it safe to always pass this flag? I mean, how come if there are real errors that require handled but are all ignored by this flag.

Thank you

[nikolay-borzov]

--no-border-checks flag has nothing to do with unmapped bytes. TypeScript creates mappings for end of line characters. A fix was introduced to address this behavior. Apparently it does not work for your case. Recently a similar issue with mapping was found in mini-css-extract-plugin. source-map-explorer makes mapping line and column checks to ensure that specified source map is valid for the file (e.g. if source map references column 50 and source has only 30 columns it might indicate specified source map and generated code mismatch). I think these checks do not make much sense (since it looks like a rare case) and decided to introduce --no-border-checks as a quick-win solution. We might remove these checks in the future.

To exclude unmapped bytes from result set --only-mapped flag.

[LouisSung]

I get it I'm using --no-border-checks and --only-mapped flags as of now and it works fine

Thanks a lot for your explanations~

[hoanggaphan]

I get it I'm using --no-border-checks and --only-mapped flags as of now and it works fine

Thanks a lot for your explanations~

Thnks a lot, it's worked for me