eirslett / frontend-maven-plugin

"Maven-node-grunt-gulp-npm-node-plugin to end all maven-node-grunt-gulp-npm-plugins." A Maven plugin that downloads/installs Node and NPM locally, runs NPM install, Grunt, Gulp and/or Karma.
Apache License 2.0
4.22k stars 868 forks source link

Allow overriding URL for musl-based NodeJS separately #965

Open breun opened 3 years ago

breun commented 3 years ago

frontend-maven-plugin uses nodeDownloadRoot to download the configured version of NodeJS. nodeDownloadRoot defaults to https://nodejs.org/dist/ when not explicitly set, but can be overridden.

When frontend-maven-plugin detects it's running on Alpine Linux, it changes the default URL to https://unofficial-builds.nodejs.org/download/release/ (https://github.com/eirslett/frontend-maven-plugin/pull/853), because that hosts NodeJS binaries that work with musl (as used by Alpine) instead of glibc.

We are using frontend-maven-plugin in a CI environment that does not have access to the public internet, so my team is overriding nodeDownloadRoot to an internal URL that provides the files from https://nodejs.org/dist/ and we provide this preconfigured to our internal teams.

However, this currently means that our preconfigured frontend-maven-plugin cannot be used on Alpine Linux, because the nodeDownloadRoot override only provides regular (glibc-based) NodeJS binaries. Some teams would like to able to use Alpine, while others use a glibc-based Linux distribution.

We have another internal URL that provides the binaries from https://unofficial-builds.nodejs.org/download/release/, but currently we cannot override the regular NodeJS download root and the alternative musl NodeJS download root separately, because frontend-maven-plugin only has a single property for this.

If frontend-maven-plugin would have a second configuration setting, we could preconfigure the plugin to work on any Linux.

My suggestion would be to support something like this:

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>com.github.eirslett</groupId>
        <artifactId>frontend-maven-plugin</artifactId>
        <version>${eirslett.frontend-maven-plugin.version}</version>
        <configuration>
          <nodeVersion>${node.version}</nodeVersion>
          <yarnVersion>${yarn.version}</yarnVersion>
          <nodeDownloadRoot>$MY_NODE_DOWNLOAD_URL</nodeDownloadRoot>
          <nodeMuslDownloadRoot>$MY_NODE_MUSL_DOWNLOAD_URL</nodeMuslDownloadRoot><!-- The new configuration property -->
        </configuration>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

https://unofficial-builds.nodejs.org/download/release/ doesn't exclusively provide musl-based builds, so the property could also be named differently. nodeUnofficialDownloadRoot maybe? Doesn't make it clearer in this context maybe.

What do you think? I think I could create a PR for this idea.

eirslett commented 3 years ago

It's possible, but I'd rather not add more configuration options to the plugin, because it's already so complex, and it's a very rarely asked-for feature. How do you use Alpine, is it in a Dockerfile that the teams control? In that case, it's easier for them to simply install node/npm in the Docker container and use that directly (or via exec-maven-plugin).

breun commented 3 years ago

We prefer using frontend-maven-plugin over exec-maven-plugin, because via frontend-maven-plugin we can manage default (LTS) versions for NodeJS and Yarn for our teams, and if they need to deviate they can override those version using a single property. Also nobody needs to care about the fact that NodeJS and Yarn are downloaded from an internal URL, because that is all managed. They can also easily switch to another OS base image and they don't need to worry about having to rewrite their Dockerfile with different packages to install, using different package manager commands. A lot of teams also use Jib instead of a Dockerfile.

The fact that frontend-maven-plugin abstracts all of that away is great, and I assume frontend-maven-plugin was created exactly for reasons like those. I understand our case of managing overridden default download root URLs might be rare, but ideally we'd like to keep benefitting from all the convenience provided by frontend-maven-plugin, but we'd also like for it to work on both Alpine Linux and more traditional libc-based Linux distributions out of the box. And for that I believe we'd need to be able to override both the regular (https://nodejs.org/dist/) and musl (https://unofficial-builds.nodejs.org/download/release/) download root URLs.