lwc

lwc copied to clipboard

Details

This PR replaces Lerna with nx in the LWC monorepo.

Along with this change includes a new versioning script for bumping the LWC versions on all packages within the monorepo.

I've also removed any references to Lerna and previous publishing scripts, eg. publish.mjs.

Nx can be configured to cache more than this PR has configured it to, ex. caching test results. I haven't configured all of the caching capabilities because this PR is focused on replacing Lerna's functionality with nx.

We can open more PR's to enable further optimizations going forward.

Does this pull request introduce a breaking change?

• ✅ No, it does not introduce a breaking change.

Does this pull request introduce an observable change?

• ✅ No, it does not introduce an observable change.

GUS work item

W-11148552

/nucleus stop

HTTP request failed

Unfortunately it looks like there is a problem with how NX is doing caching:

yarn build
rm -fr packages/@lwc/shared/{dist,types}
yarn build

If you run the above commands, then the packages/@lwc/shared/dist file will exist, but packages/@lwc/shared/types will not.

The issue seems to be that, by default, NX will cache the dist directory. But we are using the (somewhat unusual) types directory (along with dist) in some of our packages.

The fix is to add this to the individual package.json files for packages with a types directory:

    "nx": {
        "targets": {
            "build": {
                "outputs": [
                    "./dist",
                    "./types"
                ]
            }
        }
    }

I'm torn between just including nx.targets.build.outputs in every single package.json file (to be explicit), or only including it in our packages that have types.

@nolanlawson @pmdartus

I think there are two main things we get from nx that helps speed up the builds which Lerna doesn't provide:

1. Parallel builds
2. Caching

The only thing that nx doesn't provide is versioning, everything else (that we need) nx has covered.

Having said that, this PR is ready for another round of review!

Here's what I've added in the latest update:

1. Updated it to save the nx cache in circleci so that it can be shared across multiple CI runs.
2. Added the test and sauce targets to build dependencies before the commands run.
3. Added unit testing to be part of the nx caching/build strategy.

For the unit tests, I wasn't able to find a good way to replicate the test:debug and test:ci (displaying the coverage report) so I've left them as is for now.

Unfortunately it looks like there is a problem with how NX is doing caching:

yarn build
rm -fr packages/@lwc/shared/{dist,types}
yarn build

If you run the above commands, then the packages/@lwc/shared/dist file will exist, but packages/@lwc/shared/types will not.

The issue seems to be that, by default, NX will cache the dist directory. But we are using the (somewhat unusual) types directory (along with dist) in some of our packages.

The fix is to add this to the individual package.json files for packages with a types directory:

    "nx": {
        "targets": {
            "build": {
                "outputs": [
                    "./dist",
                    "./types"
                ]
            }
        }
    }

I'm torn between just including nx.targets.build.outputs in every single package.json file (to be explicit), or only including it in our packages that have types.

@nolanlawson - I opted to add the 'nx.targets.build.outputs' to every 'package.json' to be consistent with how we have the 'files' property on the 'package.json' files.

FYI @jmsjtu I bitrotted you with this merge (https://github.com/salesforce/lwc/pull/2982), apologies for that. 😅

/nucleus test

A workflow stage test has already been completed. You can still use --force to rerun the stage.

/nucleus test --force

/nucleus stop

Successfully stopped all stages for this workflow.

/nucleus test --force

❌ An unexpected error occurred while attempting to start the test stage of workflow 85067. Please try to start the stage again, or reach out to #nucleus-talk for help.

/nucleus test

yarn test:performance does not seem to be working anymore, but it seems unrelated to this change because it's failing in master. I'll look into it.

/nucleus stop

Successfully stopped all stages for this workflow.

/nucleus test

/nucleus test

/nucleus stop

Successfully stopped all stages for this workflow.

/nucleus stop

Successfully stopped all stages for this workflow.

/nucleus stop

Successfully stopped all stages for this workflow.

/nucleus test

@nolanlawson Sorry one last review request, I promise!

Could you review 2f2f02dfc4893a73276ea5090b2b14cdc83f4159?

I made some slight tweaks to the package.json and the versioning script because nucleus requires a version-source to process the release version.

It also looks like the release-npm (release job) in nucleus always runs the npm-bump-package-versions step, example.

That steps runs this command npx lerna version --no-git-tag-version --no-push --no-commit-hooks --yes --exact <LWC_VERSION>

I know you mentioned before we could potentially just use nucleus for the versioning, looks like it wouldn't take much to get it set up.

Maybe in a future PR we can simplify the release to just update the version on the root package.json and initiate a release through nucleus.

@jmsjtu I made one small tweak by running your versioning script on the existing package.json files and adding a newline to the end. (Most of the package.json files already have newlines at the end, and my editor adds them by default. 😛) Let me know what you think: 55ff32d2b

@jmsjtu Some mild nitpicks, otherwise :shipit:!