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.

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

How to release an angular library with both typescript source code and source map? #22701

Closed
1 of 15 tasks
UchihaYuki opened this issue Feb 13, 2022 · 6 comments
Closed
1 of 15 tasks

Comments

@UchihaYuki
Copy link

UchihaYuki commented Feb 13, 2022

🚀 Feature request

Command (mark with an x)

  • new
  • build
  • serve
  • test
  • e2e
  • generate
  • add
  • update
  • lint
  • extract-i18n
  • run
  • config
  • help
  • version
  • doc

Description

I want to release my angular libraries alongside their typescript source code. When people consuming my libraries, they can set break point inside my code for debugging. (I can set breakpoints for other libraries, for exmaple, rxjs. I hope I can do the same for angular libraries.)

Describe alternatives you've considered

I tried to use ng-package.json to copy my src folder to dist/my-lib/src. Then I write code to modify all dist/my-lib/**/*.map. But the breakpoints are still unbound under vscode chrome remote debug. But I can at least use the vscode go to implementation now.

@alan-agius4
Copy link
Collaborator

This is expected and working as intended. The library build pipeline includes the original contents of the TypeScript files as an embedded string in the source map. In general shipping TypeScript (.ts) in your NPM package is not considered as a good practice

The library bundle will be strictly generated conferment with the Angular package format specification.

There are a couple of ways to debug a library:

  1. Add a breakout in the FESM bundle which will map to it's original TypeScript files.
  2. Add a breakout in an application which will stepping into will also map to the original TypeScript file.

Typically, when consuming a library documentation and go to implementation to point to contracts (.d.ts) suffices as consumers should not care about implementation details of a method, class etc..

@UchihaYuki
Copy link
Author

There are a couple of ways to debug a library:

Add a breakout in the FESM bundle which will map to it's original TypeScript files.
Add a breakout in an application which will stepping into will also map to the original TypeScript file.

If I don't ship my source code, the sources in fesm2015/my-lib.mjs.map will be mapped to the location on my own PC. It won't exist on customers' PC. What do you mean by "original TypeScript files"?

In general shipping TypeScript (.ts) in your NPM package is not considered as a good practice

But it will be much convenient to debug integration of multiple big angualar libraries. Famous library like rxjs also ship its source code.

@alan-agius4
Copy link
Collaborator

If I don't ship my source code, the sources in fesm2015/my-lib.mjs.map will be mapped to the location on my own PC. It won't exist on customers' PC. What do you mean by "original TypeScript files"?

it will be mapped to the original Typescript code which is inlined in the sourcemaps itself and not the one located on your machine.

But it will be much convenient to debug integration of multiple big angualar libraries. Famous library like rxjs also ship its source code.

You don’t require to ship src for sourcemaps to point to the original TS source contents. Since TypeScript code will be inlined as part of the sourcemap itself. While rxjs does ship the sources, this is not considered the best practice and also there have been some pushbacks and concerns about doing so ReactiveX/rxjs#3753.

Overall, I don’t think that it will be a good idea to ship TypeScript sources and in general we shouldn’t change our tooling and APF specs to allow it, as it doesn’t provide much value over having inlined source contents.

@UchihaYuki
Copy link
Author

Add a breakout in the FESM bundle which will map to it's original TypeScript files.

The breakpoint in fesm2015/my-lib.js is unbound when debug under vscode.

I think, in most cases, what people will do is right click in angular app then go to implementations, then set breakpoint.
But now go to implementation will only go to d.ts, and you have to search through fesm2015/my-lib.js to find the perfect breakpoint (which not work, in my case).

@alan-agius4
Copy link
Collaborator

Make sure that you are adding the break point in the correct FESM file. Since you are using an older version of Angular, this would be located in the ivy_ngcc directory. You'd also need to enable vendor source maps as by default sourcemaps in node_modules are not picked up for performance reasons.

I think, in most cases, what people will do is right click in angular app then go to implementations, then set breakpoint.

From my understanding typically users would add a break point in their code and step-in it. Also, ES2020 is also very close to TypeScript which in many cases makes users opt not to use source maps at all when debugging libraries.

Close, since this is not something that we should be adding support in our tooling for since it offers little to no benefits for the end users and in general shipping TypeScript files is not considered a good practice.

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Mar 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants