Use project relative preference for declaration emit

[sheetalkamat]

Fixes #42349

[sheetalkamat]

@typescript-bot test this
@typescript-bot user test this

[typescript-bot]

Heya @sheetalkamat, I've started to run the extended test suite on this PR at 85db43e. You can monitor the build here.

[typescript-bot]

Heya @sheetalkamat, I've started to run the parallelized community code test suite on this PR at 85db43e. You can monitor the build here.

[sheetalkamat]

This change is so that it actually uses directory of tsconfig file and not random directory where tsc is invoked from. (eg in test added the current directory is "/")

[typescript-bot]

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

[andrewbranch]

I added project-relative as a way to use somewhat looser heuristics for auto-import paths than we do in the compiler generally, namely the existence of package.json files in source directories, which otherwise tsc would never care about unless node module resolution for a bare specifier resolved to that directory. Does #42224 not fully solve the issue? That is a much more explainable fix, if nothing else, and seems to fit nicely with an existing ethos of reusing input nodes and paths elsewhere in the transformers/emitter.

[sheetalkamat]

It does solve the issue but only if file was imported in the file, not otherwise. This would give use better paths in declaration emit. interesting thing is it didn't break anything so i wonder if this is better behavior for those derived paths. may be it is better option if importing file is project reference redirect?

[robpalme]

may be it is better option if importing file is project reference redirect?

Please try to avoid making declaration emit dependent on whether the source/destination crosses a boundary expressed specifically as a project reference.

Our higher-level tooling (think Lerna etc) constructs multi-project workspaces dynamically. The workspace is just a list of packages you want to develop together live - and the user adds and removes packages frequently in the course of developing or debugging an issue. Meaning a project might have no project references one minute (because it is being built in isolation and so only links to static/published declarations for dependencies via "paths"). Then the next minute the user wants to experiment by adding another project to the workspace, and so the tooling injects a project reference into tsconfig (causing the parent project to now consume declarations generated live from the child project's source code).

It would be odd if this lightweight switching action resulted in different behavior in declaration emit.

[sheetalkamat]

@typescript-bot pack this

[typescript-bot]

Heya @sheetalkamat, I've started to run the tarball bundle task on this PR at 28d3a36. You can monitor the build here.

[typescript-bot]

Hey @sheetalkamat, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/93415/artifacts?artifactName=tgz&fileId=8571D4CACB394041C1A919F295B6CB437DAFEB81173361A4A88885E8A6AE839602&fileName=/typescript-4.2.0-insiders.20210115.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

[sandersn]

@sheetalkamat is this obsolete now that #42224 is in? Or is it worth continuing on? If so, is it ready for review? I couldn't tell from skimming the conversation.

[sheetalkamat]

I dont think this is absolete. There is #42349 which might need this so need to investigate further and add test before this is ready for review.

[sheetalkamat]

@andrewbranch @weswigham i think we should take this PR as this does help many scenarios.. Eg #42349 where there are no project references or node_modules involved .. its all path mapping. I think declaration emit to use non relative module specifier if project crosses boundary is good thing rather than always using relative path.
Please review and weigh in again.
Thanks

[andrewbranch]

I’m not completely confident that project-relative will produce correct results 100% of the time, but I do think it will be better on average. It’s probably fine to move forward and iterate on this if we get feedback about it.