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

Npm install support #11216

Open
LecrisUT opened this issue Mar 14, 2024 · 1 comment
Open

Npm install support #11216

LecrisUT opened this issue Mar 14, 2024 · 1 comment
Labels
Needed: design decision A core team decision is required

Comments

@LecrisUT
Copy link

What's the problem this feature will solve?

Similar to the python.install feature, it would be nice to support a npm.install as well. Maybe also cargo and go?

Describe the solution you'd like

A small wrapper for npm install (and npm build?) to automatically build the packages in package.json. Having first-party support would be helpful, because than the caching can be more efficiently shared.

Alternative solutions

Manual control of cache artifacts

@stsewd stsewd added the Needed: design decision A core team decision is required label Mar 14, 2024
@agjohnson
Copy link
Contributor

We were sort of discussing this recently. Right now, our default commands executed for builds are meant to serve Python based projects. This comes from all of the tooling we directly supported historically being Python based tools -- Sphinx and Mkdocs.

More direct support for Node/etc tooling is getting into some new area for us, so we don't yet have concrete plans here. Feedback here is definitely helpful for us!

So, a few things that we've discussed at some points:

We've talked about at very least offering overrides to default build jobs. These are discussed more here:

The missing jobs right now are:

  • build.jobs.install - Override all of our install commands
  • build.jobs.build.html - Override all of our (HTML) build commands

You can sort of accomplish this now with the pre_install/post_install jobs too. But official support might look like:

build:
  jobs:
    install:
      - npm install
    build:
      html:
        - npm run build
        - ...

As far as native support for npm install in our configuration file, these additions are hard for us to maintain. So, we might instead prefer to keep npm/etc support at simply overriding build.jobs.install for now. This feels reasonable as there probably isn't much to gain from our configuration file acting as a proxy.

You can also do this with build.commands but need to control the build process entirely.

Our eventual goal here is to support/offer reusable, community build packages, where users only need to specify the tooling package and it's arguments. This is a far ways out though.

As far as caching goes, we do not cache anything between builds anyways. Each build requires a full, fresh checkout of your repository. We've tried caching layers and surprisingly saw little improvement with build time.

humitos added a commit that referenced this issue Nov 28, 2024
This PR modifies the build to not run default commands when the user doesn't
specify `sphinx` or `mkdocs` configs in the YAML file.

This allows to use the following YAML file to build with Docusaurus, for
example:

```yaml
version: 2

build:
  os: ubuntu-24.04
  tools:
    nodejs: "22"
  jobs:
    install:
      - cd docs/ && npm install
    build:
      html:
        - cd docs/ && npm run build
    post_build:
      - mkdir --parents $READTHEDOCS_OUTPUT/html/
      - cp --recursive docs/build/* $READTHEDOCS_OUTPUT/html/
```

This is the structure I've been wanting to have to allow any type of doctool to
work in our platform following the `build.jobs` pattern.

The code deployed in production doesn't allow this because it runs automatically
`create_environment`, `install_core_dependencies` and `install_requirements`
even if the project is not using Python --which is incorrect. It fails with the
generic error: " Unknown problem. There was a problem with Read the Docs while
building your documentation"

- https://app.readthedocs.org/projects/test-builds/builds/26425680/
- https://read-the-docs.sentry.io/issues/4458662274/

This PR detects if the user is defining `sphinx` or `mkdocs` and if it's not, it
doesn't run those jobs and leave the user to handle the build workflow
completely.

* Related #11216
* Related #11551
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needed: design decision A core team decision is required
Projects
None yet
Development

No branches or pull requests

3 participants