Skip to content
This repository has been archived by the owner on Dec 21, 2022. It is now read-only.

[NC-438] PIW-tools: Optimise rollup build process #926

Closed
wants to merge 12 commits into from

Conversation

wegiswes
Copy link
Contributor

@wegiswes wegiswes commented Sep 17, 2021

This PR contains

  • Bug fix
  • Feature
  • Refactor
  • Documentation
  • Other (describe)

What is the purpose of this PR?

This PR adds a formatting step to rolup. This will prettify the unpretty, auto-generated typings files.
This PR also includes a feature where you can use MX_PROJECT_PATH in combination with npm run release.

What should be covered while testing?

We should build all Native & Web widgets with this change to see if the error above is actually fixed.

@wegiswes wegiswes added enhancement New feature or request Cross-Platform Web & Native labels Sep 17, 2021
@wegiswes wegiswes requested a review from a team September 17, 2021 10:16
@wegiswes wegiswes requested a review from a team as a code owner September 17, 2021 10:16
@wegiswes wegiswes changed the title Fix Studio Pro ReferenceError related to rollup terser [NC-438] Fix Studio Pro ReferenceError related to rollup terser Sep 17, 2021
@wegiswes wegiswes changed the title [NC-438] Fix Studio Pro ReferenceError related to rollup terser [NC-438] Optimise rollup build process Sep 21, 2021
scripts/release/copyReleaseToProject.js Outdated Show resolved Hide resolved
scripts/release/copyReleaseToProject.js Outdated Show resolved Hide resolved
scripts/release/copyReleaseToProject.js Outdated Show resolved Hide resolved
jordanch
jordanch previously approved these changes Sep 23, 2021
@diego-antonelli diego-antonelli dismissed their stale review September 23, 2021 13:37

Dismissing my review in order to allow native to use their own rollup file.

Copy link
Contributor

@tamelbrun tamelbrun left a comment

Choose a reason for hiding this comment

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

Please use pluggable-widget-tools in the commit message when a commit touches the tooling, otherwise we cannot easily identify them.

@@ -194,6 +195,7 @@ export default async args => {
function getClientComponentPlugins() {
return [
isTypescript ? widgetTyping({ sourceDir: join(sourcePath, "src") }) : null,
execShellCommand(`npx pluggable-widgets-tools format`, sourcePath),
Copy link
Contributor

Choose a reason for hiding this comment

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

The PR description does not mention anything about formatting. Why do we need this step? Don't we already have Prettier configured by default as a pre-release step? To me, it feels rather intrusive for customers if the pluggable widget tools start formatting unconditionally without an easy way to override it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry I forgot to update the description. Lots of things have changed regarding rollup lately.

The reason for this step is that our generated type files are not pretty. This results in a lot of unwanted changes and means the developer has to either discard them, or include them in their commit (so it's fixed by a pre-commit hook which includes prettier).
I don't like either of those "solutions" (discard / pre-commit). Therefore I added this format step.
I can see that it could be intrusive for customers. Maybe we should add another env variable for our internal use, all though I imagine a lot of customers are running into the same issue if they prettify their codebase. What do you think would be the best solution?

Copy link
Contributor

Choose a reason for hiding this comment

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

At the very least, I would restrict the reformatting to the typings only. This is the solution that Isa chose for web, you can take a look at his PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I couldn't find Isa's solution, but I've updated the code so it only targets the typings/ folder.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

I've also suggested in that PR that this should probably be part of the widgetTyping plugin itself, in which case you would not need a separate solution here. In general, this kind of behaviour should be kept in sync between web and native, so that would be a good way to achieve that :).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree, although I didn't expect web to apply a similar solution in the end. One of the reasons why we split rollup is because native wanted this feature while web did not.. 😕

Anyhow I updated my code so formatting is now part of widgetTyping 👍🏼

Copy link
Contributor

Choose a reason for hiding this comment

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

Did you coordinate with Isa? Because if he now tries to do the same thing, one of you will get a merge conflict on the widgetTyping plugin.

I think that web definitely did not want a reformat on the entire project, which is what happened before :). I can see other advantages in splitting up the rollup config for web and native, but we definitely shouldn't introduce arbitrary divergence between the two.

Copy link
Contributor

Choose a reason for hiding this comment

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

Everything from #941 is taken care of in this PR now.

@wegiswes wegiswes changed the title [NC-438] Optimise rollup build process [NC-438] PIW-tools: Optimise rollup build process Sep 28, 2021
@@ -23,6 +23,10 @@ export function widgetTyping({ sourceDir }) {
if (!firstRun) {
await runTransformation(sourceDir);
}
await execShellCommand(
`npx pluggable-widgets-tools format:custom-paths -- "../typings/**/*.ts"`,
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we be more strict and only format the file generated by this function? You have the output, so its easy to reuse it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good one. You could let the transformPackage function return the destination path and use that to format the generated typing file.

Copy link
Contributor

@IIsaku IIsaku left a comment

Choose a reason for hiding this comment

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

Nice work Wesley! I made a few remarks for you to have a look at.

packages/tools/pluggable-widgets-tools/bin/mx-scripts.js Outdated Show resolved Hide resolved
packages/tools/pluggable-widgets-tools/bin/mx-scripts.js Outdated Show resolved Hide resolved
@@ -23,6 +23,10 @@ export function widgetTyping({ sourceDir }) {
if (!firstRun) {
await runTransformation(sourceDir);
}
await execShellCommand(
`npx pluggable-widgets-tools format:custom-paths -- "../typings/**/*.ts"`,
Copy link
Contributor

Choose a reason for hiding this comment

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

Good one. You could let the transformPackage function return the destination path and use that to format the generated typing file.

Copy link
Contributor

@IIsaku IIsaku left a comment

Choose a reason for hiding this comment

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

Nice work, two points to consider.

@tamelbrun
Copy link
Contributor

Please use pluggable-widget-tools in the commit message when a commit touches the tooling, otherwise we cannot easily identify them.

@wesleysieses Can you change the commit messages in this PR accordingly? I noticed that some new ones without the tag were added.

@wegiswes wegiswes force-pushed the fix/npm-release-error branch 2 times, most recently from 265d8c9 to bf65882 Compare October 1, 2021 12:41
@wegiswes
Copy link
Contributor Author

wegiswes commented Oct 1, 2021

Please use pluggable-widget-tools in the commit message when a commit touches the tooling, otherwise we cannot easily identify them.

@wesleysieses Can you change the commit messages in this PR accordingly? I noticed that some new ones without the tag were added.

@tamelbrun Should be fixed now, thanks! 👌🏼

@wegiswes wegiswes force-pushed the fix/npm-release-error branch 4 times, most recently from ddcf07a to 8a976c5 Compare October 12, 2021 13:45
`npx pluggable-widgets-tools format:custom-files -- ${propsTypingFilePaths
.map(f =>
platform() === "win32"
? `${f.replace(/(?<=[/\\])([^/\\]* [^/\\]*)(?=[/\\])/g, '"$1"')}`
Copy link
Contributor

@tamelbrun tamelbrun Oct 12, 2021

Choose a reason for hiding this comment

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

I have two minor comments:

  • The string template does not appear to be necessary.
  • Given that regexes can be notoriously hard to read, extracting this to a small quoteFoldersWithSpaces function would make this code document itself.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nice regex, by the way 😉

.map(f =>
platform() === "win32"
? `${f.replace(/(?<=[/\\])([^/\\]* [^/\\]*)(?=[/\\])/g, '"$1"')}`
: `'"${f}"'`
Copy link
Contributor

Choose a reason for hiding this comment

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

The inner string is now both double-quoted and single-quoted in the output on non-Windows platforms, that doesn't seem right?

@iobuhov iobuhov deleted the fix/npm-release-error branch August 26, 2022 19:58
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Cross-Platform Web & Native enhancement New feature or request
Projects
None yet
6 participants