npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@andreypopp/esy

v0.0.6

Published

Easy Package.json Sandboxes For Compilers

Downloads

199

Readme

esy

Easy Sandboxes For Compiled Languages

Rough sketch start of implementation for PackageJsonForCompilers concept. (Here, the name is esy instead of pjc).

esy seeks to support an "eject" feature, which makes PackageJsonForCompilers easy to deploy/build on hosts that don't even have node installed - they would only need make. Just copy the entire sandbox over to the host and run the makefile.

The esy command (without anything following the esy word), prints the environment for one package, taking into account variables exported by dependencies. The final goal of the esy build command is to walk the entire dependency graph, running their build commands, and running each dependency's build command in an environment computed from the esy command, for that one package.

The environments computed by esy are with respect to (sandbox root, cur package), where the sandbox root is the top level package we're building everything for, and cur package is one of the transitive dependencies. Running esy in a directory is like printing the environment as if pwd was both the sandbox root and the "currently building package".

The esy build command would walk the tree with sandbox root = topmost package, and at each node set cur package = <THIS_DEPENDENCY>, and run the build command in an environment computed based on that combination.

We'd want to generate a makefile that encodes the graph of packages, and can build everything with maximum parallelism.

Test

Built In Commands

|Command | Meaning | Implemented | |-------------------------|------------------------------------------------ |-------------| |esy | Print the environment variables for current directory as sandbox root and cur root. | Started | |esy build | Implements pjc build command from PackageJsonForCompilers proposal. Should generate Makefile | Yes | |esy any command here | Executes any command here but in the sandbox that would be printed via esy | No |

Test

Run the test. The output shows the environment computed for a single package PackageA. Some errors are logged into the comments of the output.

cd tests/TestOne/PackageA
./test.sh

The output isn't actually verified yet. We should create many more similar tests, even if they don't work correctly yet.

Next

  • Populate all of the variables in pjc proposal.
  • Should generate a build for all packages in makefile form.
  • Implement "scope" concept as described in esy.js comments.
  • Take buildTimeOnlyDependencies in order to "cut off" scope of environment variables.
  • Automatically set up _build and _install directories, populate variables accordingly.

Try it out on a sample project

https://github.com/andreypopp/esy-ocaml-project

Origins

This is a fork of dependency-env which is more stable.