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

feat: enable TypeScript project references #5155

Merged
merged 5 commits into from
Apr 22, 2020
Merged

Conversation

raymondfeng
Copy link
Contributor

@raymondfeng raymondfeng commented Apr 19, 2020

See https://www.typescriptlang.org/docs/handbook/project-references.html

Supersedes #1636
Implements #2609

TypeScript project references seem to be working with latest VSCode now. Please help verify.

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

  • npm test passes on your machine
  • New tests added or existing tests modified to cover all changes
  • Code conforms with the style guide
  • API Documentation in code was updated
  • Documentation in /docs/site was updated
  • Affected artifact templates in packages/cli were updated
  • Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

@raymondfeng raymondfeng added developer-experience Issues affecting ease of use and overall experience of LB users Internal Tooling Issues related to our tooling and monorepo infrastructore labels Apr 19, 2020
@raymondfeng raymondfeng force-pushed the ts-project-refs branch 10 times, most recently from 04fc521 to e90fad4 Compare April 20, 2020 06:09
Copy link
Member

@bajtos bajtos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @raymondfeng for starting this initiative, I am looking forward to have project references enabled 👏

Did you run the steps listed in How to test infrastructure changes? Are there any issues to be aware of?

Please make sure to update that section of our dev docs to accurately describe the new setup.

What is the impact of this change on the build time?

  • Full build from clean? npm run clean && time npm run build
  • Incremental build after no (or a small) change was made? time npm run build

With project references in place, we should get rid of top-level manually-written index.js, index.d.ts and index.ts files. Their purpose is to trick IDE into treating the entire monorepo as a single TypeScript project. That's no longer desirable, we want each package to be treated as its own project. Those index files are also causing slow build times. As I shown in #2613, we can speed up our build by getting rid of them.

.travis.yml Outdated Show resolved Hide resolved
bin/update-ts-project-refs.js Show resolved Hide resolved
packages/build/bin/compile-package.js Outdated Show resolved Hide resolved
packages/build/config/tsconfig.common.json Outdated Show resolved Hide resolved
@raymondfeng
Copy link
Contributor Author

Some smoke test results for performance:

  1. With this PR
  • First-time (clean build)
real	0m30.565s
user	0m37.962s
sys	0m3.128s
  • Second-time (incremental build)
real	0m1.476s
user	0m0.960s
sys	0m0.420s
  1. Without this PR
  • First-time
real	2m1.125s
user	7m11.410s
sys	0m24.406s
  • Second-time
real	1m12.558s
user	3m45.993s
sys	0m20.833s

The improvement is significant.

@raymondfeng raymondfeng force-pushed the ts-project-refs branch 2 times, most recently from e5560f2 to 8afd076 Compare April 20, 2020 16:43
@raymondfeng
Copy link
Contributor Author

With project references in place, we should get rid of top-level manually-written index.js, index.d.ts and index.ts files. Their purpose is to trick IDE into treating the entire monorepo as a single TypeScript project. That's no longer desirable, we want each package to be treated as its own project. Those index files are also causing slow build times. As I shown in #2613, we can speed up our build by getting rid of them.

I would like to defer this change to a follow-up PR. One of the caveats listed in the project references is that we have to run tsc -b first. I'm not sure if it's still true. See https://www.typescriptlang.org/docs/handbook/project-references.html#caveats-for-project-references.

@raymondfeng
Copy link
Contributor Author

Did you run the steps listed in How to test infrastructure changes? Are there any issues to be aware of?

Yes. I did.

@bajtos
Copy link
Member

bajtos commented Apr 21, 2020

Some smoke test results for performance:
(...)
The improvement is significant.

This is awesome, even better than I expected.

I would like to defer this change to a follow-up PR. One of the caveats listed in the project references is that we have to run tsc -b first. I'm not sure if it's still true. See https://www.typescriptlang.org/docs/handbook/project-references.html#caveats-for-project-references.

Yeah, I was thinking about deferring this part too. The current PR is large enough, it's better to work incrementally. I am happy to take a look at index changes myself after this PR is landed.

Did you run the steps listed in How to test infrastructure changes? Are there any issues to be aware of?

Yes. I did.

Cool 👏 Did you find any issues? Does everything work as before?


/**
* `tsc -b` only accepts valid arguments. `npm run build -- --<other-arg>` may
* pass in extra arguments. We need to remove such arguments.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What kind of arguments are getting in via npm run build -- --<other-arg>? If they are provided by the user (either on command line or via their package.json) then we must let them know about the problem and especially which parameters are removed by lb-tsc.

Personally, I don't think it's a good idea to add such parameter-modifications to lb-tsc, I am concerned about support and maintenance costs. IMO, we should let tsc fail the build and expect the user to fix the parameters passed tolb-tsc/tsc.

@bajtos
Copy link
Member

bajtos commented Apr 21, 2020

BTW, lb-tsc provides --copy-resources option. I don't think that's going to work with project references. IIUC, lb-tsc is invoked for the top-level monorepo-root "project" only, that calls tsc to run the build and after that individual packages are built using tsc. It's not a problem in this monorepo, because we have removed usage of that flag long time ago, but it's something to be aware of. I am not sure if there is anything we can do about that, because when we run lb-tsc for the top-level project, then it's difficult to know what lb-tsc arguments are configured by individual packages. Maybe we can put a warning to our current lb-tsc docs? (I am not sure where the docs is.)

@raymondfeng
Copy link
Contributor Author

The removal of invalid options is for npm script composition as other npm runs can trigger npm run build but npm always pass extra args to all commands.

@bajtos
Copy link
Member

bajtos commented Apr 21, 2020

The removal of invalid options is for npm script composition as other npm runs can trigger npm run build but npm always pass extra args to all commands.

I see, do you have any example?

I am concerned that some day, a developer will add a new option to npm run build script, lb-tsc will silently discard it, and the poor developer will have hard times figuring out what's going on and why their new switch is ignored. Can you please find a way how to let developers know about flags removed by the tool? E.g. use console.warn or debug logs.

@raymondfeng
Copy link
Contributor Author

I see, do you have any example?

I am concerned that some day, a developer will add a new option to npm run build script, lb-tsc will silently discard it, and the poor developer will have hard times figuring out what's going on and why their new switch is ignored. Can you please find a way how to let developers know about flags removed by the tool? E.g. use console.warn or debug logs.

It can reproduced by cd packages/context; npm test -- --timeout 5000.

There are debug statements to show how loopback:build is working.

@raymondfeng
Copy link
Contributor Author

I'm not sure why Travis build fails for some of the acceptance tests - https://github.com/strongloop/loopback-next/pull/5155/checks?check_run_id=603795936.

@bajtos
Copy link
Member

bajtos commented Apr 21, 2020

It can reproduced by cd packages/context; npm test -- --timeout 5000.

Interesting! I always thought that npm does not pass the extra arguments to pre and post scripts (pretest in this case). I guess I was wrong 🤷

There are debug statements to show how loopback:build is working.

Are you referring to the following line?

https://github.com/strongloop/loopback-next/blob/04728a07e4e22a248f09535d06ec1d3f7323e099/packages/build/bin/compile-package.js#L175

I find the message rather cryptic, how about something like this:

debug('Using the following args for tsc -b', validArgs);

I'm not sure why Travis build fails for some of the acceptance tests - https://github.com/strongloop/loopback-next/pull/5155/checks?check_run_id=603795936.

I quickly checked the error log and don't see any obvious problem 🤔

Copy link
Member

@bajtos bajtos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but we need to fix CI before this can be landed.

@raymondfeng raymondfeng merged commit 6b24a63 into master Apr 22, 2020
@raymondfeng raymondfeng deleted the ts-project-refs branch April 22, 2020 00:06
bajtos added a commit that referenced this pull request Apr 23, 2020
In #5155, we reworked our typescript setup
to leverage composite mode and project references. This breaks our
example applications when they are checked out standalone, typically
via `lb4 example`.

```sh
$ lb4 example todo
(...)
$ cd loopback4-example-todo
$ npm t
(...)
> lb-tsc

error TS6053: File '/private/packages/http-caching-proxy/tsconfig.json' not found.
error TS6053: File '/private/packages/testlab/tsconfig.json' not found.
(...)
Found 10 errors.
```

This commit fixes the problem by introducing a new step to `lb4 example`
command where we remove `references` and `compilerOptions.composite`
field from `tsconfig.json` file.

Signed-off-by: Miroslav Bajtoš <[email protected]>
bajtos added a commit that referenced this pull request Apr 23, 2020
In #5155, we reworked our typescript setup
to leverage composite mode and project references. This breaks our
example applications when they are checked out standalone, typically
via `lb4 example`.

```sh
$ lb4 example todo
(...)
$ cd loopback4-example-todo
$ npm t
(...)
> lb-tsc

error TS6053: File '/private/packages/http-caching-proxy/tsconfig.json' not found.
error TS6053: File '/private/packages/testlab/tsconfig.json' not found.
(...)
Found 10 errors.
```

This commit fixes the problem by introducing a new step to `lb4 example`
command where we remove `references` and `compilerOptions.composite`
field from `tsconfig.json` file.

Signed-off-by: Miroslav Bajtoš <[email protected]>
bajtos added a commit that referenced this pull request Apr 23, 2020
In #5155, we reworked our typescript setup
to leverage composite mode and project references. This breaks our
example applications when they are checked out standalone, typically
via `lb4 example`.

```sh
$ lb4 example todo
(...)
$ cd loopback4-example-todo
$ npm t
(...)
> lb-tsc

error TS6053: File '/private/packages/http-caching-proxy/tsconfig.json' not found.
error TS6053: File '/private/packages/testlab/tsconfig.json' not found.
(...)
Found 10 errors.
```

This commit fixes the problem by introducing a new step to `lb4 example`
command where we remove `references` and `compilerOptions.composite`
field from `tsconfig.json` file.

Signed-off-by: Miroslav Bajtoš <[email protected]>
bajtos added a commit that referenced this pull request Apr 23, 2020
In #5155, we reworked our typescript setup
to leverage composite mode and project references. This breaks our
example applications when they are checked out standalone, typically
via `lb4 example`.

```sh
$ lb4 example todo
(...)
$ cd loopback4-example-todo
$ npm t
(...)
> lb-tsc

error TS6053: File '/private/packages/http-caching-proxy/tsconfig.json' not found.
error TS6053: File '/private/packages/testlab/tsconfig.json' not found.
(...)
Found 10 errors.
```

This commit fixes the problem by introducing a new step to `lb4 example`
command where we remove `references` field from `tsconfig.json` file
and set the field `compilerOptions.composite` to `false`.

Signed-off-by: Miroslav Bajtoš <[email protected]>
bajtos added a commit that referenced this pull request Apr 23, 2020
In #5155, we reworked our typescript setup
to leverage composite mode and project references. This breaks our
example applications when they are checked out standalone, typically
via `lb4 example`.

```sh
$ lb4 example todo
(...)
$ cd loopback4-example-todo
$ npm t
(...)
> lb-tsc

error TS6053: File '/private/packages/http-caching-proxy/tsconfig.json' not found.
error TS6053: File '/private/packages/testlab/tsconfig.json' not found.
(...)
Found 10 errors.
```

This commit fixes the problem by introducing a new step to `lb4 example`
command where we remove `references` field from `tsconfig.json` file
and set the field `compilerOptions.composite` to `false`.

Signed-off-by: Miroslav Bajtoš <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developer-experience Issues affecting ease of use and overall experience of LB users Internal Tooling Issues related to our tooling and monorepo infrastructore
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants