uswds / uswds-compile

Simple Gulp 5 functions for copying USWDS static assets and transforming USWDS Sass into browser-readable CSS.
Other
20 stars 12 forks source link

Installation fails on linux/arm64 #25

Closed bkline closed 2 years ago

bkline commented 2 years ago

Running npm install @uswds/compile --save-dev as instructed by the documentation fails with the error message

Unexpected platform or architecture: linux/arm64

image

Ignoring all the deprecation warnings, is there a path which works around this failure (skipping the extra bells and whistles this package is trying to pull in) enabling the use of sass to compile the .scss files, or is the only alternative to use the pre-compiled CSS version of USWDS?

bkline commented 2 years ago

I'm hoping there actually is a middle path here, based on the language in the What You Need section of the Getting started for developers page, which implies that all that is needed is

mejiaj commented 2 years ago

@bkline I thought node support in general was limited in ARM devices.

Would you mind giving us a little more information? What version of node and what Linux distribution are you using?

bkline commented 2 years ago

@mejiaj This is in a Dockerfile based on the ubuntu:jammy image. Here's the relevant portion:

ENV NVM_DIR /usr/local
ENV NODE_VERSION 16.14.2
RUN curl --silent -o- \
    https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash
RUN . $NVM_DIR/nvm.sh && \
    nvm install $NODE_VERSION && \
    nvm alias default $NODE_VERSION && \
    nvm use default
RUN npm install -g npm@8.6.0

Using the most recent version of node as instructed in the documentation.

bkline commented 2 years ago

I thought node support in general was limited in ARM devices.

It's not node. That part's OK. The problem is that the only documented path to getting the pieces in place for compiling the stylesheets has a dependency on getting a bunch of other things installed. The dependency that tripped up the installer was PhantomJS. In a perfect world it would be nice to have all those other tools, but they're not all necessary for the basic task of compiling the .scss files. That's why I was asking above if there's documentation squirreled away somewhere for a workaround which would get what's really needed for that task set up while the installation dependency failure is being addressed.

mgwalker commented 2 years ago

USWDS and this compile utility both rely on gulp-svg-sprite to stitch SVGs together into a sprite sheet. That library has a downstream dependency on PhantomJS which has been deprecated for 4 years. The dependency tree is something like this:

@uswds/compile
|____ gulp-svg-sprite@1.5.0
    |____ svg-sprite@1.5.4
        |___ phantomjs-prebulit@2.5.4 - uses or downloads prebuilt PhantomJS

There are no versions of the intermediary dependencies that don't ultimately rely on PhantomJS. PhantomJS can probably be built on arm64, but there's no prebuilt binary, and because the project is suspended, there likely won't ever be one. phantomjs-prebuilt will use an existing PhantomJS if it finds one of the same version that it expects, so it might be possible to jump through some hoops to manually build it in your arm64 environment and let phantomjs-prebuilt find that. Note that even when the project was actively supported, the maintainers discouraged people from building from source, but maybe you don't really have another choice.

Ideally USWDS (which itself also depends on gulp-svg-sprite) and this compile helper would migrate to a gulp plugin that doesn't rely on PhantomJS, but until then, it's a significant burden to build USWDS on arm64 architectures.

(This is not a dunk on USWDS. svg-sprite uses a browser rendering environment to accurately measure the dimensions of source SVGs, since SVGs themselves are unreliable when it comes to their sizes. Whether or not that's applicable to USWDS, I don't know, but whatever would replace gulp-svg-sprite would probably also need some way of understanding the true rendered size of SVGs in order to resize them properly onto the sprite sheet.)

mejiaj commented 2 years ago

@mgwalker @bkline I've tested installing and running on a M1 Macbook air without any issues. But will continue to try to reproduce.

Specs macOS Monterey v12.3.1 Macbook Air (M1, 2020) node v16.14.2

bkline commented 2 years ago

@mejiaj Did you tell Docker to emulate the amd64 platform? If not, this is good news.

mejiaj commented 2 years ago

This was in OSX, not Docker sorry.

It's in response to a slack message about Apple ARM64 chips and getting uswds/compile building.

bkline commented 2 years ago

👍