[bug#43840] gnu: Add esbuild.

On Wed, Oct 07, 2020 at 02:31:24AM +0000, Ryan Prior via Guix-patches via wrote:
> * gnu/packages/web.scm (esbuild): New variable.
> ---
>  gnu/packages/web.scm | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
> index b798e0abca..1e2f2e7e10 100644
> --- a/gnu/packages/web.scm
> +++ b/gnu/packages/web.scm
> @@ -1345,6 +1345,34 @@ used to validate and fix HTML data.")
>      (home-page "http://tidy.sourceforge.net/")
>      (license (license:x11-style "file:///include/tidy.h"))))
>  
> +(define-public esbuild
> +  (package
> +    (name "esbuild")
> +    (version "0.7.11")
> +    (source
> +     (origin
> +       (method git-fetch)
> +       (uri (git-reference
> +             (url "https://github.com/evanw/esbuild")
> +             (commit (string-append "v" version))))
> +       (file-name (git-file-name name version))
> +       (sha256
> +        (base32
> +         "08lx1i0s1q3my6x4csz746rc3c2fl4p0hyrwx4rpx80gwwjj1i11"))))
> +    (build-system go-build-system)
> +    (arguments
> +     '(#:import-path "github.com/evanw/esbuild/cmd/esbuild"
> +       #:unpack-path "github.com/evanw/esbuild"))
> +    (inputs
> +     `(("go-golang-org-x-sys" ,go-golang-org-x-sys)))
> +    (home-page "https://github.com/evanw/esbuild")
> +    (synopsis "Bundler and minifier tool for JavaScript and TypeScript")
> +    (description
> +     "The esbuild tool provides a unified bundler, transpiler and
> +minifier.  It packages up JavaScript and TypeScript code, along with JSON
> +and other data, for distribution on the web.")
> +    (license license:expat)))
> +
>  (define-public tinyproxy
>    (package
>      (name "tinyproxy")
> -- 
> 2.17.1
> 

First pass, I don't see a vendor directory that needs to be deleted, and
it does seem to only really depend on go-golang-org-x-sys, which is
nice. There is an npm directory which is where the compiled binaries are
placed, there are a couple in the checked out repo.


`esbuild --help` still works after removing the npm directory.

Is it worth trying to run some of the test suite? I see there are a
couple of 'make check' type targets in the Makefile at the root of the
repository and currently there are none run during the build.

Hey Efraim, thank you for your comments!

On Wednesday, October 7th, 2020 at 6:34 AM, Efraim Flashner <efraim@flashner.co.il> wrote:

> There is an npm directory which is where the compiled binaries are
> placed, there are a couple in the checked out repo.

The compiled binaries might be placed there by the gnu-build-system, but the go-build-system does not put binaries there by itself. (Note that their make target explicitly specifies output directories.)

I think our build totally ignores this directory, so it shouldn't matter whether we delete it, but if you think removing the unneeded directory improves the package I'll update the patch with a snippet.

>     Is it worth trying to run some of the test suite? I see there are a
>     couple of 'make check' type targets in the Makefile at the root of the
>     repository and currently there are none run during the build.

It would be nice to run their tests, but the test system currently assumes network access to install some various JavaScript dependencies using npm. We might patch the test system and vendor in the deps (used only for testing,) what do you think?

Ryan

On Thu, Oct 08, 2020 at 02:08:36AM +0000, Ryan Prior wrote:
> Hey Efraim, thank you for your comments!
> 
> On Wednesday, October 7th, 2020 at 6:34 AM, Efraim Flashner <efraim@flashner.co.il> wrote:
> 
> > There is an npm directory which is where the compiled binaries are
> > placed, there are a couple in the checked out repo.
> 
> The compiled binaries might be placed there by the gnu-build-system, but the go-build-system does not put binaries there by itself. (Note that their make target explicitly specifies output directories.)
> 
> I think our build totally ignores this directory, so it shouldn't matter whether we delete it, but if you think removing the unneeded directory improves the package I'll update the patch with a snippet.

It's important to not ship any precompiled binaries so go ahead and
remove them in a snippet.

> >     Is it worth trying to run some of the test suite? I see there are a
> >     couple of 'make check' type targets in the Makefile at the root of the
> >     repository and currently there are none run during the build.
> 
> It would be nice to run their tests, but the test system currently assumes network access to install some various JavaScript dependencies using npm. We might patch the test system and vendor in the deps (used only for testing,) what do you think?
> 

I was able to run some of the test suite with the following arguments section:

(arguments
 '(#:import-path "github.com/evanw/esbuild/cmd/esbuild"
   #:unpack-path "github.com/evanw/esbuild"
   #:phases
   (modify-phases %standard-phases
     (replace 'check
       (lambda* (#:key tests? unpack-path #:allow-other-keys)
         (if tests?
           (with-directory-excursion (string-append "src/" unpack-path)
             (invoke "make" "test-go"))
           #t))))))

Unfortunately it also depends on github.com/kylelemons/godebug/diff, but
it doesn't look like it has any dependants. With that added as a
native-input I think it's ready.

> Ryan

Thanks

On Sunday, October 11th, 2020 at 10:28 AM, Efraim Flashner <efraim@flashner.co.il> wrote:
> It's important to not ship any precompiled binaries so go ahead and
> remove them in a snippet.

You got it.

> I was able to run some of the test suite with the following arguments section:
> [snip]
> Unfortunately it also depends on github.com/kylelemons/godebug/diff, but
> it doesn't look like it has any dependants. With that added as a
> native-input I think it's ready.

I do have a package for godebug. If you want to run all the tests, it goes in to the `scripts` module and runs `npm install` to pull in various test dependencies: https://github.com/evanw/esbuild/blob/master/scripts/package.json

But running just the "test-go" target seems like a good compromise for now! Maybe we can revisit this once node packaging in Guix is in a better state (which esbuild may help us with.)

I'll send my godebug package and an updated esbuild package with the code to run the tests.

Ryan