cache
proposal-built-in-modules | cache | |
---|---|---|
4 | 40 | |
891 | 4,274 | |
0.3% | 1.7% | |
0.0 | 7.2 | |
11 months ago | 15 days ago | |
HTML | TypeScript | |
BSD 2-clause "Simplified" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
proposal-built-in-modules
-
Turboprop: JS Arrays as Property Accessors!?!
There is proposal for stdlib, but it will take some time until (if ever) it will reach stage 4.
-
Don't make me think, or why I switched to Rails from JavaScript SPAs
The working group most in charge of JS is ECMA's TC-39 (TC => Technical Committee) [0]. They've been taking a very deliberate, slow path to expanding the "standard" library because they take a very serious view of backwards compatibility on the web. Some proposals were shifted because of conflicts with ancient versions of things like MooTools still out in the wild, for instance. (This was the so-called "Smooshgate" incident [1].)
This may speed up a bit if the Built-In Modules proposal [2] passes, which would add a deliberate `import` URL for standard modules which would give a cleaner expansion point for new standard libraries over adding more global variables or further expanding the base prototypes (Object.prototype, Array.prototype, etc) in ways that increasingly likely have backwards compatibility issues.
TC-39 works all of their proposals in the open on Github [3] and it can be a fascinating process to watch if you are interested in the language's future direction.
[0] https://tc39.es/
[1] https://developers.google.com/web/updates/2018/03/smooshgate
[2] https://github.com/tc39/proposal-built-in-modules
[3] https://github.com/tc39/proposals
-
What NPM Should Do Today to Stop a New Colors Attack Tomorrow
There is a TC39 proposal for a "Javascript Standard Library." It's at stage 1, which is better than stage 0.
https://github.com/tc39/proposal-built-in-modules
-
[AskJS] What is the thing you hate the most about JS?
The standard library is a tough one. There is a proposal for built-in modules but it is very early days and miles away from what is needed. Clojure ships with functions that make the likes of Lodash and Ramda redundant. I think for a dynamic language an extensive library of functions for manipulating collections is essential. It is a real thing that once dynamic language codebases grow too big, they become a challenge to maintain. Therefore having functions that do a lot of common tasks for you mitigates that issue. Paired with immutability, lots of code just becomes data passing through pipelines, giving less surface area for bugs and making everything more concise and declarative.
cache
-
GitHub Actions could be so much better
> with no persistent storage
There's https://github.com/actions/cache though?
-
Optimizing GitHub Actions Performance: Enhance Workflows with Caching
Use Cache Actions: GitHub Actions provides cache actions that simplify caching implementation. The @actions/cache JavaScript library is a popular choice for managing caching in workflows. It offers flexible options for storing and retrieving cache artifacts based on keys, scopes, and paths.
-
Speeding up GitHub Actions with npm cache
GitHub maintain a set of repos called actions. One of which is called cache.
-
How I Sliced Deployment Times to a Fraction and Achieved Lightning-Fast Deployments with GitHub Actions
By utilizing the actions/cache action action, we implemented a strategy to store and retrieve dependencies, preventing redundant installations.
-
Use GitHub Actions to Make Your GitHub Profile Dynamic
I do think it's good practice to enable caching, such that your script doesn't hit RubyGems / pip / npm / etc every time it runs.
That way at least the automation activity stays entirely within the GitHub / Azure network.
It looks like you can do that for Ruby by adding this:
https://github.com/actions/cache/blob/master/examples.md#rub...
- uses: ruby/setup-ruby@v1
-
A guide to using act with GitHub Actions
➜ getting-started-with-act git:(master) act -j build WARN ⚠ You are using Apple M1 chip and you have not specified container architecture, you might encounter issues while running act. If so, try running it with '--container-architecture linux/amd64'. ⚠ [Node.js CI/build] 🚀 Start image=node:16-buster-slim [Node.js CI/build] 🐳 docker pull image=node:16-buster-slim platform= username= forcePull=false [Node.js CI/build] 🐳 docker create image=node:16-buster-slim platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] [Node.js CI/build] 🐳 docker run image=node:16-buster-slim platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] [Node.js CI/build] ☁ git clone 'https://github.com/actions/setup-node' # ref=v3 [Node.js CI/build] ☁ git clone 'https://github.com/actions/cache' # ref=v3 [Node.js CI/build] ☁ git clone 'https://github.com/actions/upload-artifact' # ref=v3 [Node.js CI/build] ⭐ Run Main actions/checkout@v3 [Node.js CI/build] 🐳 docker cp src=/Users/andrewevans/Documents/projects/getting-started-with-act/. dst=/Users/andrewevans/Documents/projects/getting-started-with-act [Node.js CI/build] ✅ Success - Main actions/checkout@v3 [Node.js CI/build] ⭐ Run Main Use Node.js 16.x [Node.js CI/build] 🐳 docker cp src=/Users/andrewevans/.cache/act/actions-setup-node@v3/ dst=/var/run/act/actions/actions-setup-node@v3/ [Node.js CI/build] 🐳 docker exec cmd=[node /var/run/act/actions/actions-setup-node@v3/dist/setup/index.js] user= workdir= [Node.js CI/build] 💬 ::debug::isExplicit: [Node.js CI/build] 💬 ::debug::explicit? false
- duplicated cache by cache action
-
runner image with MS office installed - do-able? is there a better way?
You could try to find some point in the process where you can set up Actions caches with actions/cache, otherwise Container customization for Self-Hosted Runners is currently in Beta.
-
[Question] Decrease Docker image's build time
I would configure Github Actions cache so Docker doesn't have to compile all layers from scratch every time
-
The strongest principle of the blog's growth lies in the human choice to deploy it
In the copied example, npm caching is done via actions/cache@v2 action. But we can simplify our workflow by dropping this step and using built-in functionality for caching
What are some alternatives?
openapi-typescript-codegen - NodeJS library that generates Typescript or Javascript clients based on the OpenAPI specification
upload-artifact
proposal-pattern-matching - Pattern matching syntax for ECMAScript
sccache - Sccache is a ccache-like tool. It is used as a compiler wrapper and avoids compilation when possible. Sccache has the capability to utilize caching in remote storage environments, including various cloud storage options, or alternatively, in local storage.
Nest - A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications with TypeScript/JavaScript 🚀
act - Run your GitHub Actions locally 🚀
proposal-observable - Observables for ECMAScript
actions-runner-controller - Kubernetes controller for GitHub Actions self-hosted runners
redwood - The App Framework for Startups
setup-buildx-action - GitHub Action to set up Docker Buildx
proposal-record-tuple - ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!
checkout - Action for checking out a repo