Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add "sourceMapDir", "declarationMapDir", "inlineDeclarationMap", and "declarationMapInlineSources" compiler options #38966

Open
5 tasks done
PetaSoft opened this issue Jun 7, 2020 · 3 comments
Open
5 tasks done

Add "sourceMapDir", "declarationMapDir", "inlineDeclarationMap", and "declarationMapInlineSources" compiler options #38966

PetaSoft opened this issue Jun 7, 2020 · 3 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@PetaSoft
Copy link

PetaSoft commented Jun 7, 2020 •
edited
Loading

Search Terms

TypeScript, Compiler Options, Source Maps, Declaration Files

Suggestion

Currently, there exist the TypeScript compiler options sourceMap, inlineSourceMap, inlineSources, declaration, declarationMap, and declarationDir but there is no way to tell the compiler the folder for the source map files and the declaration map files. The declaration map cannot be part of the declaration file, too, and the source code cannot be inlined into a declaration map.

Therefore, please add the compiler options:

  • sourceMapDir: the folder of the emitted source map files;
  • declarationMapDir: the folder of the declaration map files;
  • inlineDeclarationMap: the declaration map is put into the declaration file using a comment;
  • declarationMapInlineSources: the source code becomes part of the declaration map similar to the option inlineSources for generated JavaScript files inlining TypeScript sources.

The options inlineDeclarationMap and declarationMapInlineSources should also be usable together. It is similar to using inlineSourceMap and inlineSources together.

Using Gulp together with gulp-typescript and gulp-sourcemaps there is already the possibility to specify a source map folder and declaration map folder using sourcemaps.write("<folder>", options) but it would be better to have that possibility as part of a TypeScript compiler option.

Use Cases

Of course, these compiler options are not necessary in most cases but they open up more flexibility to the user, and the implemetation should not be very difficult.

At least the option inlineDeclarationMap would reduce the cluttering of files in the declarationDir folder, and declarationMapInlineSources together with inlineDeclarationMap would make it possible to ship a declaration file with the sources as one file.

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@PetaSoft PetaSoft changed the title Add "sourceMapDir", "declarationMapDir", "inlineDeclarationMap", "declarationMapInlineSources" compiler options Add sourceMapDir, declarationMapDir, inlineDeclarationMap, and declarationMapInlineSources compiler options Jun 7, 2020
@PetaSoft PetaSoft changed the title Add sourceMapDir, declarationMapDir, inlineDeclarationMap, and declarationMapInlineSources compiler options Add "sourceMapDir", "declarationMapDir", "inlineDeclarationMap", and "declarationMapInlineSources" compiler options Jun 7, 2020
@RyanCavanaugh RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Jun 15, 2020
@tomrav
Copy link

tomrav commented Jun 7, 2021 •
edited
Loading

I'm one of the maintainers of Stylable, a CSS pre-processor and I'm currently working on a feature that would allow us to generate definition files and source mapping for every stylesheet the user creates.

I'm really interested in two features that this issue suggests, those being allowing source-maps to be in-lined in definition files, and the ability to place definition files anywhere in the project and have them point to the file they're describing.

The way things currently are, a lot of files end up being generated in development mode and really clutter the user's project.

@tzachbon
Copy link

It would be a great addition and for sure will make my src dir leaner.
At least an inline source map and inline declaration file would help a lot!

@MartinJohns MartinJohns mentioned this issue Jan 26, 2022
Closed
5 tasks
copybara-service bot pushed a commit to material-components/material-web that referenced this issue Aug 24, 2022
@aomarks @copybara-github
chore: Don't publish .ts, .scss, or testing files
96f24ac 
Before this change, we publish .ts source files to the same directory as the .js/.d.ts files to npm.

That means when a consumer imports a @material/web module with TypeScript, TypeScript prefers the .ts file over the .d.ts file when to load that module's types.

That in turn means the consumer's TypeScript type-checks the entire @material/web .ts file, including its private implementation details (private fields, etc.). If the consumer's tsconfig.json is configured more strictly than @material/web's was (e.g. if noUnusedParameters is true), or if some additional ambient types are loaded (e.g. @types/node is installed, which changes the signature of setTimeout), they would get a compile error.

This change stops publishing .ts files to npm to solve that problem for consumers.

This also includes some related changes:

- Sets inlineSources to true. This puts the .ts file contents directly inside the .js.map file, instead of linking to the .ts path. Otherwise sourcemaps would not work.

- Sets declarationMap to false. This removes the .d.ts.map files, which are not useful without the .ts paths, because there is no equivalent to inlineSources for declarationMap (see microsoft/TypeScript#38966).

- Replaces .npmignore blocklist with package.json files allowlist (which I find to be a bit safer), and adds new omissions for testing files, as well as .scss files, which don't need to be published.

Note that this doesn't solve the problem when using "npm link" for local cross-package development, because in that case the .ts files will still be present. So a better solution to this problem would be to have a separate src/ directory for .ts source files. That will require a Copybara transform to move the files. We can discuss this separately and do it as a followup if agreed.

PiperOrigin-RevId: 469775605
@copybara-service copybara-service bot mentioned this issue Aug 24, 2022
Merged
copybara-service bot pushed a commit to material-components/material-web that referenced this issue Aug 24, 2022
@aomarks @copybara-github
chore: Don't publish .ts or testing files
0776883 
Before this change, we publish .ts source files to the same directory as the .js/.d.ts files to npm.

That means when a consumer imports a @material/web module with TypeScript, TypeScript prefers the .ts file over the .d.ts file when to load that module's types.

That in turn means the consumer's TypeScript type-checks the entire @material/web .ts file, including its private implementation details (private fields, etc.). If the consumer's tsconfig.json is configured more strictly than @material/web's was (e.g. if noUnusedParameters is true), or if some additional ambient types are loaded (e.g. @types/node is installed, which changes the signature of setTimeout), they would get a compile error.

This change stops publishing .ts files to npm to solve that problem for consumers.

This also includes some related changes:

- Sets inlineSources to true. This puts the .ts file contents directly inside the .js.map file, instead of linking to the .ts path. Otherwise sourcemaps would not work.

- Sets declarationMap to false. This removes the .d.ts.map files, which are not useful without the .ts paths, because there is no equivalent to inlineSources for declarationMap (see microsoft/TypeScript#38966).

- Replaces .npmignore blocklist with package.json files allowlist (which I find to be a bit safer), and adds new omissions for testing files, which don't need to be published.

Note that this doesn't solve the problem when using "npm link" for local cross-package development, because in that case the .ts files will still be present. So a better solution to this problem would be to have a separate src/ directory for .ts source files. That will require a Copybara transform to move the files. We can discuss this separately and do it as a followup if agreed.

PiperOrigin-RevId: 469775605
copybara-service bot pushed a commit to material-components/material-web that referenced this issue Aug 24, 2022
@aomarks @copybara-github
chore: Don't publish .ts or testing files
96805fe 
Before this change, we publish .ts source files to the same directory as the .js/.d.ts files to npm.

That means when a consumer imports a @material/web module with TypeScript, TypeScript prefers the .ts file over the .d.ts file when to load that module's types.

That in turn means the consumer's TypeScript type-checks the entire @material/web .ts file, including its private implementation details (private fields, etc.). If the consumer's tsconfig.json is configured more strictly than @material/web's was (e.g. if noUnusedParameters is true), or if some additional ambient types are loaded (e.g. @types/node is installed, which changes the signature of setTimeout), they would get a compile error.

This change stops publishing .ts files to npm to solve that problem for consumers.

This also includes some related changes:

- Sets inlineSources to true. This puts the .ts file contents directly inside the .js.map file, instead of linking to the .ts path. Otherwise sourcemaps would not work.

- Sets declarationMap to false. This removes the .d.ts.map files, which are not useful without the .ts paths, because there is no equivalent to inlineSources for declarationMap (see microsoft/TypeScript#38966).

- Replaces .npmignore blocklist with package.json files allowlist (which I find to be a bit safer), and adds new omissions for testing files, which don't need to be published.

Note that this doesn't solve the problem when using "npm link" for local cross-package development, because in that case the .ts files will still be present. So a better solution to this problem would be to have a separate src/ directory for .ts source files. That will require a Copybara transform to move the files. We can discuss this separately and do it as a followup if agreed.

PiperOrigin-RevId: 469833263
@dummdidumm dummdidumm mentioned this issue Jan 31, 2023
Open
@NWYLZW
Copy link

NWYLZW commented Dec 13, 2024

inlineDeclarationMap is quite useful. It can help me better do upper-level encapsulation on TypeScript.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@tomrav @RyanCavanaugh @tzachbon @NWYLZW @PetaSoft