VSCode auto-import doesn't use library importPath

Current Behavior

In a workspace with both apps and libraries, the auto-import in VSCode doesn’t attempt to import from libraries by name, but rather the full relative path.

E.g.

Auto import from '../../../libs/test-lib-js/src' function testLibJs(): string

Expected Behavior

Auto import from '@nx-test/test-lib' function testLib(): string

Steps to Reproduce

• npx create-nx-workspace@latest nx-test --preset=apps --nx-cloud=false
• cd nx-test
• npm i -D @nrwl/node
• npx nx generate @nrwl/js:library --name=test-lib --testEnvironment=node --no-interactive
• npx nx generate @nrwl/node:application --name=test-app --no-interactive
• Open the project in VSCode
• Open the apps/test-app/src/main.ts file in the editor
• Type testLib

Failure Logs

None

Environment

VSCode Version: 1.59.0 Nx Console v17.14.1

$ nx report

 >  NX   Report complete - copy this into the issue template

   Node : 16.14.0
   OS   : darwin x64
   npm  : 8.5.0
   
   nx : 13.9.4
   @nrwl/angular : undefined
   @nrwl/cypress : undefined
   @nrwl/detox : undefined
   @nrwl/devkit : 13.9.4
   @nrwl/eslint-plugin-nx : 13.9.4
   @nrwl/express : undefined
   @nrwl/jest : 13.9.4
   @nrwl/js : 13.9.4
   @nrwl/linter : 13.9.4
   @nrwl/nest : undefined
   @nrwl/next : undefined
   @nrwl/node : 13.9.4
   @nrwl/nx-cloud : undefined
   @nrwl/nx-plugin : undefined
   @nrwl/react : undefined
   @nrwl/react-native : undefined
   @nrwl/schematics : undefined
   @nrwl/storybook : undefined
   @nrwl/web : undefined
   @nrwl/workspace : 13.9.4
   typescript : 4.5.5
   rxjs : 6.6.7
   ---------------------------------------
   Community plugins:

(node:69330) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field module resolution of the package at /Users/ehaynes/workspace/tmp/nx-test/node_modules/tslib/package.json.
Update this package.json to use a subpath pattern like "./*".
(Use `node --trace-deprecation ...` to show where the warning was created)

[ehaynes99]

Ok, finally figured it out. Sorry if you wasted too much time on this…

It’s due to the typescript.preferences.importModuleSpecifier setting in VSCode. Looks like a bit of a goldilocks solution, as there are 4 options, and 3 of them break this in one way or another:

• shortest - ❌ coin toss, as it’s based on the character count in the from 'characters'; statement. Surprised this is actually an option, TBH, and the default, no less. Seems really silly that renaming a file would change the way it gets imported…
• relative - ❌ what I had. It works within the library, but causes the behavior I was seeing in consuming projects
• non-relative - ❌ inverse of the prior, this works in the consuming project(s), but then not within the same project. A peer file in the library would become e.g. import { testLib } from 'libs/test-lib/src/lib/test-lib';. This fails the linter with Projects cannot be imported by a relative or absolute path, and must begin with a npm scope eslint(@nrwl/nx/enforce-module-boundaries). I didn’t see any of its options that looked like it would allow this, but maybe there is one (or could be). I like the idea in general, as there aren’t confusing levels of ../../../../ everywhere, but is completely dependent on the baseUrl setting in tsconfig to work, so I gave up on it years ago.
• project-relative - ✔️ And we have a winner! It’ll use relative imports within the same project, and package imports in the consuming project(s)

[ehaynes99]

It’s actually a VSCode setting, not a tsconfig option. Not sure if you want to get into the business of modifying .vscode/settings.json in generated workspaces, but it might be a case where nx should be opinionated by default.

• @nrwl/jest and @nrwl/linter already create/modify .vscode/extensions.json (without asking about IDE of choice, though it’s a reasonable assumption with only the one official editor extension)
• The default of shortest will probably work out most of the time as package names are usually shorter than relative paths, but it will seem like random breakage when it doesn’t.
• The default lint scripts including --fix will change it anyway

Note: there is a corresponding javascript.preferences.importModuleSpecifier setting for js, which functions in the same way.