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

[INFRA] Split build output directories #1004

Merged
merged 12 commits into from
Jan 12, 2021
Merged

Conversation

tbouffard
Copy link
Member

@tbouffard tbouffard commented Jan 5, 2021

Previously, everything was built into the 'dist' folder so it was hard to know
which build part generated which files.
So, the output directories have been split:

  • Non bundled Javascript: build/lib (only generated when running the tsc command)
  • Demo: build/demo
  • Development: build/public
  • Bundles: dist (as before)

In addition, the gitignore, eslintignore and clean script have been simplified to remove
output folders that are not generated anymore (coverage related).
The tsconfig.json has been simplified: remove extra configurations only run by tsc. We
don't generate sourceMap nor declaration files as they are only useful for bundles (declaration)
or when running the development server (sourceMap).

Previously, everything was built into the 'dist' folder so it was hard to know
which build part generated which files.
So, the output directories have been split:
  - Non bundled Javascript: lib (only generated when running the tsc command)
  - Demo: build/demo
  - Development: build/public
  - Bundles: dist (as before)

In addition, the gitignore and clean script have been simplified to remove
output folders that are not generated anymore (coverage related).
@tbouffard tbouffard added the chore Build, CI/CD or repository tasks (issues/PR maintenance, environments, ...) label Jan 5, 2021
@tbouffard tbouffard marked this pull request as draft January 5, 2021 07:28
@tbouffard tbouffard marked this pull request as ready for review January 5, 2021 09:35
tsconfig.json Outdated
@@ -1,8 +1,8 @@
{
"compilerOptions": {
"declaration": true,
"declarationDir": "./dist",
"outDir": "./dist",
"declarationDir": "./lib",
Copy link
Member

Choose a reason for hiding this comment

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

Is it normal that the generated files for the type definition are in the dist folder ?
I don't have 'lib' generated folder.

Copy link
Member Author

Choose a reason for hiding this comment

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

Files are generated in the lib directory only when running with the tsc command or build triggered by IDE (like IntelliJ).
When running with rollup, the typescript plugin seems generating the definition files in the same folder as the one where the bundle is generated, so the dist folder.

Copy link
Member Author

@tbouffard tbouffard Jan 8, 2021

Choose a reason for hiding this comment

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

I have changed the tsconfig.json because I would like we provide a non bundled version of the ESM package. We could use the lib folder to package it in the npm package.

Copy link
Member

Choose a reason for hiding this comment

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

For me, it's weird to have the generated files not at the same place if we us rollup or tsc.

@aibcmars A idea ?

Copy link
Contributor

Choose a reason for hiding this comment

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

at first glance it is strange indeed
I have started to check it up locally - should be able to tell something more soon

Copy link
Member Author

Choose a reason for hiding this comment

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

Just remember that rollup generates bundles (single javascript files with all the lib) and the purpose of this PR is to split the output directories based on usage of the generated resources. Mainly to avoid the current mess we have and which requires cleaning: we have everything in the dist folder, we don't know where the files come from (see commit and PR description).

The dev bundle for the demo/development is now generated in a subfolder of the build and the dev http server uses it.
The bundles for the npm package stay in the dist folder to avoid package breaking change.
We have each javascript generated files from each typescript files in the lib folder. We may in the future use them directly to generate the bundles without having to rebuild them with the typescript plugin. This is what roughjs does for instance: https://github.com/rough-stuff/rough/blob/v3.1.0/package.json#L10

Copy link
Contributor

@aibcmars aibcmars Jan 8, 2021

Choose a reason for hiding this comment

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

split is a great idea 👍
bundles ok to have it under /dist 👍

however, I do not really see the interest in having the additional /lib directory

--- edit
OK, I see now your previous comment @tbouffard
so it is just to provide types for simple esm 👍

Copy link
Contributor

Choose a reason for hiding this comment

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

I am still wondering?
[in the case for not bundled esm]

Isn't it enough to just have the definitions under /dist

Copy link
Member Author

Choose a reason for hiding this comment

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

We could talk about this directly on next week.

As having a lib folder may only be useful in case of a non bundled ESM module (not done for now), we could generate the single javascript files in build/lib or build/bin to hide them.
For the declaration files, we can store them wherever we want as far as we reference the right path in the package.json types field.

Copy link
Member Author

Choose a reason for hiding this comment

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

We (@csouchet, @aibcmars and @tbouffard) have decided to

  • store the tsc outputs to build/lib
  • don't generate declarations when running tsc as they are never used

Copy link
Member

@csouchet csouchet left a comment

Choose a reason for hiding this comment

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

When I run the command npm run lint (after running npm run build-utils), I have the following error:

...../BPMN-Visualization/scripts/utils/dist/src/model/bpmn/json/Semantic.d.ts
  25:18  error  An empty interface is equivalent to `{}`  @typescript-eslint/no-empty-interface
  26:18  error  An empty interface is equivalent to `{}`  @typescript-eslint/no-empty-interface
  27:18  error  An empty interface is equivalent to `{}`  @typescript-eslint/no-empty-interface

✖ 3 problems (3 errors, 0 warnings)

I think that something is missing in .eslintignore file, or the output of utils.rollup.config.js is wrong.

@tbouffard
Copy link
Member Author

When I run the command npm run lint (after running npm run build-utils), I have the following error:

...../BPMN-Visualization/scripts/utils/dist/src/model/bpmn/json/Semantic.d.ts
  25:18  error  An empty interface is equivalent to `{}`  @typescript-eslint/no-empty-interface
  26:18  error  An empty interface is equivalent to `{}`  @typescript-eslint/no-empty-interface
  27:18  error  An empty interface is equivalent to `{}`  @typescript-eslint/no-empty-interface

✖ 3 problems (3 errors, 0 warnings)

I think that something is missing in .eslintignore file, or the output of utils.rollup.config.js is wrong.

I have reproduced the issue with the master branch (commit a1760c5), so it seems not related to the changes proposed here.
@csouchet do you want us to create an issue for this?

@csouchet
Copy link
Member

csouchet commented Jan 8, 2021

When I run the command npm run lint (after running npm run build-utils), I have the following error:

...../BPMN-Visualization/scripts/utils/dist/src/model/bpmn/json/Semantic.d.ts
  25:18  error  An empty interface is equivalent to `{}`  @typescript-eslint/no-empty-interface
  26:18  error  An empty interface is equivalent to `{}`  @typescript-eslint/no-empty-interface
  27:18  error  An empty interface is equivalent to `{}`  @typescript-eslint/no-empty-interface

✖ 3 problems (3 errors, 0 warnings)

I think that something is missing in .eslintignore file, or the output of utils.rollup.config.js is wrong.

I have reproduced the issue with the master branch (commit a1760c5), so it seems not related to the changes proposed here.
@csouchet do you want us to create an issue for this?

👍

I think we should create a issue 🙂 --> done in #1020

As tsc is only run by IDE and lint command
disable declaration and sourceMap files generation as they are not useful in
this case.
@csouchet csouchet added the rebase needed 💥 Pull request that must be rebased on the latest master commit prior being reviewed or merged label Jan 12, 2021
Copy link
Contributor

@aibcmars aibcmars left a comment

Choose a reason for hiding this comment

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

LGTM

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@tbouffard tbouffard merged commit 4bde056 into master Jan 12, 2021
@tbouffard tbouffard deleted the infra/split_output_directories branch January 12, 2021 13:40
@tbouffard tbouffard removed the rebase needed 💥 Pull request that must be rebased on the latest master commit prior being reviewed or merged label May 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Build, CI/CD or repository tasks (issues/PR maintenance, environments, ...)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants