Create and build modern JavaScript projects with zero initial configuration.

Last update: Aug 3, 2022

Create and build modern JavaScript applications with zero initial configuration

Neutrino combines the power of webpack with the simplicity of presets.

NPM version NPM downloads Build Status Netlify Status

https://github.com/neutrinojs/neutrino


Neutrino is a companion tool which lets you build web and Node.js applications with shared presets or configurations. It intends to make the process of initializing and building projects much simpler by providing minimal development dependencies.

Neutrino uses webpack to build both web and Node.js projects by providing complete build presets which can be shared across targets and projects. You can use Neutrino base presets to get started building a variety of projects, create your own presets by extending the Neutrino core ones to be shared across your own projects or even by the community. Presets can even be manipulated on a project-by-project basis to handle almost any build situation your preset doesn't cover.

Documentation

See the Neutrino docs for details on installation, getting started, usage, and customizing.

Contributing

Thank you for wanting to help out with Neutrino! We are very happy that you want to contribute, and have put together this guide to help you get started. We want to do our best to help you make successful contributions and be part of our community.

GitHub

https://github.com/neutrinojs/neutrino/
Comments
  • 1. Neutrino 9 beta/release candidate feedback

    Hi!

    We've just published a beta release of Neutrino 9 and are keen to have people trying it out/giving feedback. Notable changes:

    • now using webpack 4, Babel 7, ESLint 6, and latest versions of test runners.
    • significant performance improvements (see here).
    • switched from using webpack/ESLint/test runner's APIs to using their native CLIs - which fixes a number of bugs, and means that the full set of CLI features are available for each, not just what we've emulated via the API.
    • the neutrino --inspect feature now produces a fully-working webpack config, for easier debugging.

    Full changelogs:

    The docs for the new version can be found here: ~https://master.neutrinojs.org~ https://neutrinojs.org/

    Note that during the beta phase, you'll need to explicitly install the @next version of any Neutrino monorepo packages when following the docs, otherwise you will install the latest stable (v8.3.0) packages instead.

    For example, to use v9's create-project, run:

    # NPM
    npx @neutrinojs/[email protected] <directory-name>
    
    # Yarn
    # (There's a bug with `yarn create` and using a version number, so we run the commands
    #  manually. Make sure the directory returned by `yarn global bin` is on `PATH` first.)
    yarn global add @neutrinojs/[email protected]
    create-project <directory-name>
    

    Or to upgrade an existing project, modify the neutrino and @neutrinojs/* entries in your package.json to use version ~^9.0.0-rc.5~ ^9.0.0 and then see: ~https://master.neutrinojs.org/migration-guide/~ https://neutrinojs.org/migration-guide/

    If you find any bugs (including things in the migration guide/docs that aren't clear enough) please comment here or file issues, so we can sort out any rough edges :-)

    Many thanks!

    Reviewed by edmorley at 2018-09-21 12:33
  • 2. Remove package.json configuration in favor of an rc file

    Using package.json for overrides can be quite limiting. I'd like to consider having a neutrinorc.js (name negotiable of course) file which is a merging of "simple" and "advanced" configuration overrides. We could keep pretty much everything the same, with the benefit that simpler configuration could utilize JS instead of being limited to JSON.

    It may seem odd, but we could vary how this file works based on the export.

    module.exports = {
      use: [alpha, beta, gamma],
      options: {...},
      config: {...}
    };
    
    module.exports = neutrino => {
      // ...
    };
    

    Basically if the exports are an object, we could treat them very similarly to how we do with the package.json content. If the exports are a function, it can just be a piece of middleware to load. The tricky part is determining precedence. Does the rc file take precedence over --use middleware, or vice versa?

    Going this route we eliminate the need for users to manually specify in their package.json that they are using an override file, since we can pick it up automatically by name.

    Thoughts?

    Reviewed by eliperelman at 2017-05-04 01:42
  • 3. Unable to create eslintrc for IDE linter

    I am unclear on the process on how to create a proper eslintrc for my IDE. I have read the docs here and created an .eslintrc.js file with this:

    const { Neutrino } = require('neutrino');
    const api = Neutrino();
    
    module.exports = api.call('eslintrc');
    

    Running my linter I get:

    Cannot read config file: /node-starter-master/.eslintrc.js
    Error: Cannot find module '.neutrinorc.js'
    

    This is the part I am unclear on. Docs mention creating a Neutrino API but I am not sure what goes in there. I have added:

    module.exports = {
      use: [
         "neutrino-preset-airbnb-base",
          "neutrino-preset-node",
          "neutrino-middleware-eslint"
      ]
    }
    

    But that did not help at all.

    Can someone clarify this process? Thank you.

    Reviewed by cyberwombat at 2017-06-17 00:31
  • 4. Only allow functions as middleware

    Addresses the comment in https://github.com/neutrinojs/neutrino/issues/1129#issuecomment-444504351

    cc: @yordis

    • Switches API to only support functions as middleware
    • No more package loading, packages must be manually required
    • Add new migrate tool which codemods a .neutrinorc.js array and string formats to the function call format
    • Tests updated
    • Documentation updated
    • Migration guide updated
    Reviewed by eliperelman at 2018-12-08 22:47
  • 5. Morph Neutrino API and CLI into middleware injectors for external CLI tools

    Edited to reflect current state of PR.

    Fixes #708. Fixes #736. Fixes #870. Fixes #842. Closes #773. Closes #839. Closes #849.

    Outstanding issues to file:

    • [x] Update docs to reflect these API changes (#896)
    • [x] ~~Determine need for config-loading bins instead of forcing config file boilerplate (still unsure if we should do this because of IDE integration)~~
    • [x] Modify stats to produce friendlier build output (#897)

    This patch is a work-in-progress, and is quite the overhaul of Neutrino into something different. Right now there is no change to the documentation, which I will change if we decide to move forward with this.

    This patch morphs Neutrino into a "preset engine" for transforming managed webpack configuration into a format that can be consumed by other CLI tools. No longer would we wrap external CLI tools like webpack, eslint, jest, karma, mocha, stylelint, etc. Instead, Neutrino could augment these tools by exposing methods for returning usable configuration.

    This approach gives the user control of their CLI tool back, and they can programmatically invoke Neutrino to load their configuration, and override however they like:

    webpack --mode production
    
    // webpack.config.js
    const neutrino = require('neutrino');
    
    // Load with no config overrides:
    module.exports = neutrino().webpack();
    
    // Load with config overrides:
    module.exports = neutrino().webpack(config => {
      // return whatever config you want
    });
    
    // Load with no config overrides using low-level API:
    module.exports = neutrino().output('webpack');
    
    // Load with config overrides using low-level API:
    module.exports = neutrino().output('webpack', config => {
      // return whatever config you want
    });
    

    The same works for ESLint and friends too (except for mocha, since it has no config file we can be required from):

    eslint src
    
    // .eslintrc.js
    const neutrino = require('neutrino');
    
    // Load with no config overrides:
    module.exports = neutrino().eslintrc();
    
    // Load with config overrides:
    module.exports = neutrino().eslintrc(config => {
      // return whatever config you want, like manipulating rules, etc.
    });
    

    • This approach is predicated on having middleware defined in .neutrinorc.js, which shouldn't change at all.
    • ~~This does do away with a bunch of CLI functionality like --inspect or --use, but those become less useful if we are just an interface to external CLI tools. We can discuss potentially bringing those back.~~ This is now back in the form of the CLI with neutrino --inspect.
    • ~~All environment variables are gone. We rely only on webpack's mode value.~~ We internally only use webpack's mode value, but still set process.env.NODE_ENV if not set based on the mode, or defaulted to production.
    • ~~There is no longer a create-project tool, since we cannot force users to choose between competing tools like webpack-cli or webpack-command, and webpack-dev-server or webpack-serve.~~ The create-project tool is back, and we opt for webpack-cli and webpack-dev-server as opinions for now.

    I'm sure there are other major things I am neglecting to mention. Let's discuss! I see so many benefits to this, including reduced maintenance burden and the ability to allow people to use Neutrino without dumping their existing tools.

    cc: @mozilla-neutrino/core-contributors

    Reviewed by eliperelman at 2018-05-07 14:21
  • 6. Pluggable event architecture mode, new test presets

    @helfi92 forgive me :laughing:

    So, this patch attempts to make Neutrino a bit more pluggable. By defining new events that preset authors can attach to, they can hook into the lifecycle of Neutrino and make changes.

    What this means for the "test" command is that without a preset that's listening for the "test" event, it will essentially do nothing. It is up to test preset authors to listen for this event, do some kind of build or compilation if necessary, then execute tests. You can see how I accomplished this with 3 different test presets: mocha, Karma, and Jest.

    Let me know what you think. I'll merge this probably tomorrow, then start in on docs.

    Reviewed by eliperelman at 2017-02-10 20:34
  • 7. Feature request: command to output final webpack config

    I recently started a project to try out Neutrino and while the initial setup was pretty easy, as soon as I wanted to make a change to the (eventual) webpack configuration I struggled to work out how to do it.

    My first attempt to understand exactly what was ending up in webpack was to try to get ahold of the configuration object that webpack would receive. I was surprised to find there was no way to make neutrino output it, either using a --verbose flag or with a separate command. In the end I just added a custom preset which would print it out.

    One of the biggest problems I observed using Grunt in production is that plugins you'd add would each modify the grunt configuration object, so that the actual configuration of tasks that'd be run would pass through many (often invisible) intermediate states before being used, making debugging impossible. I see a similarity here, in that after applying a couple of presets I had no way to know what webpack configuration was actually being used.

    I think it'd be a good idea to make the underlying configuration more transparent to users - give them a way to see what it is before and after applying presets, and with different config properties switched on/off, and encourage them to use it in the documentation.

    Moreover it'd give people a way to "eject" from Neutrino (borrowing the terminology from create-react-app), should they need to.

    Reviewed by wmadden at 2017-03-05 09:59
  • 8. Copying static assets to places other than neutrino.options.output/static

    Currently when copying static assets, we copy like so: to: basename(neutrino.options.static)

    This means if we have [source]/static/foo.bar it copied to [output]/static/foo.bar: https://github.com/mozilla-neutrino/neutrino-dev/blob/master/packages/neutrino-preset-web/index.js#L160

    This makes it impossible to copy anywhere but [output]/static, which may not be ideal.

    For example, you may wish to copy the contents of [source]/static directly to neutrino.options.output for files you might want at the root of your output (e.g. robots.txt, manifests).

    Changing the to to neutrino.options.output would give users more flexibility.

    Anything in source/static would get copied, so if you wanted it in output/static/foo.bar you would put it in source/static/static/foo.bar. source/static/robots.txt would get copied to output/robots.txt.

    Configurable option

    And/or it would be nice if something like staticOutput were a configurable destination. Consider this config:

    {
      options: {
        source: './app',
        output: './public/assets',
        entry: './js/index.js',
      }
    }
    

    Now I want a static file (e.g. robots.txt) copied to ./public (not ./public/assets). If we were able to configure staticOutput or something similar, we could set that to ./public and all would be well.

    I can work on a PR but I just wanted to get this out there for input.

    Reviewed by timkelty at 2017-06-29 05:21
  • 9. API: Presets as code, middleware injection

    In order to support a better middleware story (for reasons below), I think handling requireing should be removed from the Neutrino API, and pushed into the CLI. Basically we switch the constructor to do nothing, and introduce something like .use() for injecting presets. This makes module resolution better for Neutrino, while giving preset authors and extenders a more consistent custom configuration API (i.e. death to .custom).

    Prototyping and experimentation is happening at #86.

    EDIT: This has evolved into something a little different than proposed below, see comments for current direction. Keeping this here for posterity.


    Presets as code

    The Neutrino constructor will no longer take an array of preset names/paths. Instead, a .use() or similar would accept a preset as code, probably some kind of middleware function:

    use(preset) {
      preset(this);
    }
    

    package.json configuration

    I'm thinking that merging of package.json data should also be moved into the CLI. We already have a mechanism for merging data, so the CLI just needs to call this on the configuration after .useing all the presets

    const api = new Neutrino();
    
    api.use(require('preset-alpha'));
    api.use(require('preset-beta'));
    api.config.merge(require('package.json').config.neutrino);
    

    Along those lines, we should probably change the schema of config data in package.json so it can be aggregated into a single namespace. Looking at html and neutrino and custom and presets et al is...meh.

    Maybe just a top-level "neutrino" is OK.

    {
      "neutrino": {
        "presets": ["neutrino-preset-react"],
        "config": { "publicPath": "./" },
        "jest": { "bail": true },
        "mocha": { "reporter": "nyan" }
      }
    }
    

    Middleware configuration

    The .custom configuration object is a hack that needs to go. Making preset authors manually put configuration on this, with no way to automatically merge this back from package.json makes things annoying. This blocks #23, and you can see evidence of this mess in the Jest preset. it would be nice if preset authors could also use the middleware concept to inject preset-specific configuration with automatic merging from additional arbitrary keys from the package.json neutrino object, e.g. jest, mocha. Maybe if .use() takes a key as well.

    use(name, preset) {
      const custom = this.middlewareConfig[name];
      preset(this, custom);
    }
    
    // ...
    
    module.exports = (neutrino, options) => {
      const mochaConfig = { ...defaults, ...options };
    };
    

    I know this is a lot of changes, so I'm saving this for v5 (obviously since these are breaking changes). I'd appreciate any thoughts on this, recommendations, or better practices.

    Reviewed by eliperelman at 2017-02-28 20:18
  • 10. Refactor imagemin plugin to fix minification when used with libraries

    This fixes #670. Turns out the problem is not babel-minify, but rather some kind of interference between the imagemin plugin we were using and creating libraries.

    I switched to a different imagemin plugin with a nice API, which let us cut out some code and direct dependencies. @timkelty what do you think?

    Reviewed by eliperelman at 2018-01-15 15:46
  • 11. Support options for server-side html

    @eliperelman Starting this PR just for a spot for discussion

    This initially started as https://github.com/timkelty/neutrino-packages/tree/master/packages/neutrino-preset-web-ssr, which extended web and reconfigured.

    Global changes

    • [x] Always clean output dir, not just on build. This is an easy way for a server-side app to know if it should serve the revved assets (from manifest), or if you are running the dev-server.
    • [x] Add options.publicPath and pass it to output.publicPath and devServer.publicPath
    • [x] Normalize devServer.publicPath as a root-relative url
    • [x] change options.html to options.htmlTemplate and make options.html a bool option
    • [x] Make all paths predictable (non-revved) when neutrino.options.command === 'start' Applicable to anything that uses url-loader (https://github.com/mozilla-neutrino/neutrino-dev/pull/435)

    If options.html === false:

    • [x] do not use neutrinojs/html-template and associated plugins
    • [x] use webpack-manifest-plugin
    • [x] If options.devServer.proxy is a string (eg http://localhost:8080), set defaults for http-proxy-middleware assuming user wants to proxy all requests but webpack assets
    Reviewed by timkelty at 2017-11-15 13:51
  • 12. Build library for the browser

    Hi, I have a library which consists of a single class which is the default export from src/index.js. I'd like the built library to be able to be included via a browser script tag. It builds successfully but what is exported is a module not a class, so in order to use the class I need to reference it as Clusterer.default instead of just Clusterer. This is what my neutrinorc.js looks like:

    const library = require("@neutrinojs/library");

    module.exports = {
      options: {
        root: __dirname
      },
      use: [
        library({
          name: "Clusterer",
          libraryTarget: "window",
          target: "web"
        }),
        (neutrino) => neutrino.config.externals(undefined)
      ]
    };
    

    I'm sure this is super easy to configure but I'm struggling to see how to do it!

    Reviewed by aratcliffe at 2022-08-04 05:53
  • 13. refactor: replace deprecated String.prototype.substr()

    Reviewed by CommanderRoot at 2022-03-25 23:04
  • 14. Bump karma from 5.2.3 to 6.3.16

    Bumps karma from 5.2.3 to 6.3.16.

    Release notes

    Sourced from karma's releases.

    v6.3.16

    6.3.16 (2022-02-10)

    Bug Fixes

    • security: mitigate the "Open Redirect Vulnerability" (ff7edbb)

    v6.3.15

    6.3.15 (2022-02-05)

    Bug Fixes

    v6.3.14

    6.3.14 (2022-02-05)

    Bug Fixes

    • remove string template from client code (91d5acd)
    • warn when singleRun and autoWatch are false (69cfc76)
    • security: remove XSS vulnerability in returnUrl query param (839578c)

    v6.3.13

    6.3.13 (2022-01-31)

    Bug Fixes

    • deps: bump log4js to resolve security issue (5bf2df3), closes #3751

    v6.3.12

    6.3.12 (2022-01-24)

    Bug Fixes

    • remove depreciation warning from log4js (41bed33)

    v6.3.11

    6.3.11 (2022-01-13)

    Bug Fixes

    • deps: pin colors package to 1.4.0 due to security vulnerability (a5219c5)

    ... (truncated)

    Changelog

    Sourced from karma's changelog.

    6.3.16 (2022-02-10)

    Bug Fixes

    • security: mitigate the "Open Redirect Vulnerability" (ff7edbb)

    6.3.15 (2022-02-05)

    Bug Fixes

    6.3.14 (2022-02-05)

    Bug Fixes

    • remove string template from client code (91d5acd)
    • warn when singleRun and autoWatch are false (69cfc76)
    • security: remove XSS vulnerability in returnUrl query param (839578c)

    6.3.13 (2022-01-31)

    Bug Fixes

    • deps: bump log4js to resolve security issue (5bf2df3), closes #3751

    6.3.12 (2022-01-24)

    Bug Fixes

    • remove depreciation warning from log4js (41bed33)

    6.3.11 (2022-01-13)

    Bug Fixes

    • deps: pin colors package to 1.4.0 due to security vulnerability (a5219c5)

    6.3.10 (2022-01-08)

    Bug Fixes

    • logger: create parent folders if they are missing (0d24bd9), closes #3734

    ... (truncated)

    Commits
    • ab4b328 chore(release): 6.3.16 [skip ci]
    • ff7edbb fix(security): mitigate the "Open Redirect Vulnerability"
    • c1befa0 chore(release): 6.3.15 [skip ci]
    • d9dade2 fix(helper): make mkdirIfNotExists helper resilient to concurrent calls
    • 653c762 ci: prevent duplicate CI tasks on creating a PR
    • c97e562 chore(release): 6.3.14 [skip ci]
    • 91d5acd fix: remove string template from client code
    • 69cfc76 fix: warn when singleRun and autoWatch are false
    • 839578c fix(security): remove XSS vulnerability in returnUrl query param
    • db53785 chore(release): 6.3.13 [skip ci]
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    Reviewed by dependabot[bot] at 2022-03-02 02:38
  • 15. Support webpack-dev-server v4

    Bug or issue?

    Please try to answer the following questions:

    • What version of Neutrino are you using? 9.5.0
    • Are you trying to use any presets? If so, which ones, and what versions?
    • Are you using the Yarn client or the npm client? What version? 1.22.5
    • What version of Node.js are you using? 16.13.2
    • What operating system are you using? Linux
    • What did you do? Upgraded the webpack-dev-server package from v3 to v4 https://github.com/mozilla/treeherder
    • What did you expect to happen? No issue
    • What actually happened, contrary to your expectations? Several failures to launch the frontend container because manual migrations were necessary, including for neutrino (see bug 1755334)

    Webpack v4 migration guide

    Modification necessary:

    There are other files which also use these attributes.

    Reviewed by Archaeopteryx at 2022-02-14 17:56
  • 16. Update dependency eslint-config-airbnb to v19

    Mend Renovate

    This PR contains the following updates:

    | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | eslint-config-airbnb | ^18.2.1 -> ^19.0.0 | age | adoption | passing | confidence |


    Release Notes

    airbnb/javascript

    v19.0.4

    Compare Source

    v19.0.3

    Compare Source

    v19.0.2

    Compare Source

    v19.0.1

    Compare Source

    v19.0.0

    Compare Source


    Configuration

    📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

    🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

    ♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

    🔕 Ignore: Close this PR and you won't be reminded about this update again.


    • [ ] If you want to rebase/retry this PR, click this checkbox.

    This PR has been generated by Mend Renovate. View repository job log here.

    Reviewed by renovate[bot] at 2021-11-13 21:51
  • 17. Alternative output without deleting other files

    Bug or issue?

    issue

    Please try to answer the following questions:

    • What version of Neutrino are you using? 9.5.0

    • Are you trying to use any presets? If so, which ones, and what versions? no

    • Are you using the Yarn client or the npm client? What version? npm 6.14.12

    • What version of Node.js are you using? v14.16.1

    • What operating system are you using? MacOS BigSur

    • What did you do? I would like to specify an alternative folder for the build and tried the options.output option with a path to public www folder

    • What did you expect to happen? the files are build, but the files should be created without deleting all other files in this path before!

    • What actually happened, contrary to your expectations? the files are build there, but all other necessary files are deleted there.

    Feature request or enhancement?

    It's more a (bug)fix!

    Please describe your request in detail. Use the following questions as guidance:

    • What is the goal of the change? usability, flexiblity...

    • What are the pros and cons of the change? usability, flexiblity...

    • Could this dramatically improve the experience of our users? of course.

    Reviewed by kuehn-sba at 2021-10-22 12:39
Zero-config CLI for TypeScript package development
Zero-config CLI for TypeScript package development

Despite all the recent hype, setting up a new TypeScript (x React) library can be tough. Between Rollup, Jest, tsconfig, Yarn resolutions, ESLint, and

Aug 6, 2022
Set up a modern web app by running one command.

Create React App Create React apps with no build configuration. Creating an App – How to create a new app. User Guide – How to develop apps bootstrapp

Aug 3, 2022
Enjoy React, Redux, and React-Router, with zero build configuration.
Enjoy React, Redux, and React-Router, with zero build configuration.

react-redux-starter-kit This is yet another single page web application template using React. However, this project attempts to balance simplicity wit

Jul 25, 2022
Parcel is a zero configuration build tool for the web📦🚀
Parcel is a zero configuration build tool for the web📦🚀

Parcel is a zero configuration build tool for the web. It combines a great out-of-the-box development experience with a scalable architecture that can take your project from just getting started to massive production application.

Aug 6, 2022
Initial directory structure and package.json as a seed for new React based projects.

React Project Seed This serves as a seed for starting new React projects. It's less of a boilerplate and more of a suggested directory structure that

Apr 7, 2020
A template to create a React Library. Zero configuration, just use!

React lib template ?? A simple React lib template based on Parcel and Jest. Usage use this template for your next React lib, modify it and run npm run

May 9, 2022
Mar 5, 2022
🃏 RNN Screens - a set of methods to help build initial screens for RNN without hassle. Includes screens registration and predictable navigation between them.
🃏 RNN Screens - a set of methods to help build initial screens for RNN without hassle. Includes screens registration and predictable navigation between them.

Purpose of RNN Screens is to simplify and accelerate the process of React Native App development with React Native Navigation. It is not a replacement

Jul 21, 2022
Beautiful, Zero Configuration, Toast Messages for React. Only ~ 4kb gzip, with styles and icons
Beautiful, Zero Configuration, Toast Messages for React. Only ~ 4kb gzip, with styles and icons

Cogo Toast Beautiful, Zero Configuration, Toast Messages for React ~4kb gzip (with styles and icons) https://cogoport.github.io/cogo-toast/ Install vi

Jul 29, 2022
👻 Zero-configuration framework-agnostic static prerendering for SPAs
👻 Zero-configuration framework-agnostic static prerendering for SPAs

react-snap Pre-renders a web app into static HTML. Uses Headless Chrome to crawl all available links starting from the root. Heavily inspired by prep

Aug 4, 2022
Zero-Configuration Reactive forms for Svelte
Zero-Configuration Reactive forms for Svelte

Formula + Beaker Δ→ Reactive Forms for Svelte Documentation Changelog svelte-formula is a Library for use with Svelte that super-charges your ability

Jul 24, 2022
Zero configuration Preact widgets renderer in any host DOM
Zero configuration Preact widgets renderer in any host DOM

Preact Habitat A 900 Bytes module for that will make plugging in Preact components and widgets in any CMS or website as fun as lego! Demos Login Widge

Jul 29, 2022
✨ Create server-rendered universal JavaScript applications with no configuration
✨ Create server-rendered universal JavaScript applications with no configuration

Universal JavaScript applications are tough to setup. Either you buy into a framework like Next.js or react-server, fork a boilerplate, or set things

Jul 31, 2022
✨ Create server-rendered universal JavaScript applications with no configuration
✨ Create server-rendered universal JavaScript applications with no configuration

Universal JavaScript applications are tough to setup. Either you buy into a framework like Next.js or Nuxt, fork a boilerplate, or set things up yours

Aug 4, 2022
Create-serverless-api - Create Serverless APIs with no infra configuration
Create-serverless-api - Create Serverless APIs with no infra configuration

Create Serverless API Create Serverless APIs with no infra configuration. It is

Jun 7, 2022
:rocket: A basis for reducing the configuration of your projects with nextJS, best development practices and popular libraries in the developer community.
:rocket: A basis for reducing the configuration of your projects with nextJS, best development practices and popular libraries in the developer community.

We spend time using good community practices to make your project scalable. ?? A basis for reducing the configuration of your projects with Next.js, b

Jul 27, 2022
Initial proyect whit react.js

Getting Started with Create React App This project was bootstrapped with Create React App. Available Scripts In the project directory, you can run: np

Jan 16, 2022
Tutorial from the channel I want to be a dev for beginners on the front-end. Here we have the initial steps for testing in react.

Tutorial from the channel I want to be a dev for beginners on the front-end. Here we have the initial steps for testing in react.

Jun 1, 2022
Configuration to build React Native apps with ES6 using webpack and Babel

React Native in ES6 with webpack and Babel DEPRECATED! It's possible to write React Native apps in ES6+ using babel-loader and webpack. Check better a

Feb 14, 2022