Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@networkteam/frontend-scripts

Package Overview
Dependencies
Maintainers
6
Versions
47
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@networkteam/frontend-scripts

networkteam asset build scripts

  • 6.0.5
  • latest
  • Source
  • npm
  • Socket score

Version published
Weekly downloads
64
Maintainers
6
Weekly downloads
 
Created
Source

nwt-frontend-scripts

A webpack based workflow to create frontend-assets.

Features

  • Browser-Ready Javascript from ESNext-Modules
  • CSS-Generation from SCSS with autoprefixer
  • Icon-Sprite Generation from SVG files
  • Asset-Resolver and copier

Getting started

To use this workflow in your projects, install the package with npm or yarn

npm install @networkteam/frontend-scripts

Define variables in your package.json:

{
  "basePackageName": "Customer.Base",
  "sitePackageName": "Customer.Site"
}

Alternatively set the variables BASE_PACKAGE_NAME and SITE_PACKAGE_NAME in an .env file in the directory of your package.json. This is mandatory when using workspaces in a monorepo as package-variables are not always available in the workspace.

Copy the scripts to your package.json:

  "scripts": {
    "build": "npm run webpack",
    "build:dev": "npm run webpack:dev",
    "start": "npm run webpack:watch",
    "test": "npm run webpack:test",
    "test-watch": "npm run webpack:test-watch",
    "webpack": "networkteam-asset-build prod",
    "webpack:dev": "networkteam-asset-build dev",
    "webpack:watch": "networkteam-asset-build watch",
    "webpack:test": "networkteam-asset-build test",
    "webpack:test-watch": "networkteam-asset-build test-watch"
  },

Webpack relies on four entry points to generate JS and CSS Assets:

  • header.js: %PROJECTROOT%/Resources/Private/Javascript/header.js
  • footer.js: %PROJECTROOT%/Resources/Private/Javascript/footer.js
  • main.css: %PROJECTROOT%/Resources/Private/Scss/main.scss
  • print.css: %PROJECTROOT%/Resources/Private/Scss/print.scss

Start the npm task:

npm start // file watcher with hot reload
npm run build:dev // Development build
npm run build // Production build
npm run test // Testing with code coverage recap
npm run test-watch // Run watcher for TDD

Note: Webpack generates a JS-File for every entry point including JS-Files. This will be improved in future Versions of webpack

The generated files will be copied to %PROJECTROOT%/Resources/Public/Dist including the assets used in CSS (e.g. bg-images or fonts). The paths for the CSS Assets are automatically corrected to the new path by webpack.

Using Aliases

This workflow automatically provides aliases for an easier import from different folders:

  • rootPath: The root folder of your project
  • baseJavascript: Javascript components from base package (%BASEROOT%/Resources/Private/Javascript)
  • baseStyles: Styles from basePackage (%BASEROOT%/Resources/Private/Scss use e.g ~baseStyles/main to import main.scss)
  • modernizr: Auto-Generated modernizr file (see below)

Icon Sprite

Every SVG-File located in %BASEROOT%/Resources/Private/Icons will be included in an automatically generated Svgsprite. The sprite itself will be stored in %BASEROOT%/Resources/Public/Dist and a SCSS-File can be found in %BASEROOT%/Resources/Private/Scss/_sprite.scss. This SCSS-File includes the mixins to use the icon on every element (@include sprite(%FILENAME%)) although this way is not encouraged due to repeated server requests.

To prevent Iconsprite from being built, use the --noIconSprite flag in your npm scripts. This might be useful when on projects where you don't want to do that for each build.

Live Reloading

Hot or live reloading is supported by default in development mode. In certain projects it makes sense to disable live reloading and refresh the view manually (e.g. in forms).

To disable live reloading, use the --noLivereload flag in your npm scripts.

Environment Variables

By default the scripts pass two environment variables to use in your code: NODE_ENV and CUSTOMER_NAME, that can be accessed via process.env. If you need additional variables e.g. to define an api endpoint, you have to prefix this variable with NWT_APP_.

.env

NWT_APP_ENDPOINT = http://localhost:3000

api.js
const endpoint = process.env.NWT_APP_ENDPOINT

Add own configuration

If you need a special configuration for your Project, you can add a custom webpack.js to your project root. It will be included automatically:

module.exports = function(env, args) {
  return {
      output: {
          path: newOutputPath
      }
  };
};

If you want to adapt predefined rules and merge them to one, you may do so by matching test-expression:

module.exports = function(env, args) {
  return {
    module: {
      rules: [
        {
          test: /\.(sass|scss)$/,  // use same expression used by plugin to merge
          ...
        }
      ]
    },
  };
};

To remove entry points from webpack, you can set them to null in your own configuration

When a plugin is defined in custom webpack config that is already defined in common.webpack.js it is treated as one plugin that takes the default config and merges config of custom Webpack-Plugin deeply into it. Deeply merging class constructors only goes so far. If a default value of any used plugin in custom webpack config is initialized then it will overwrite the value defined in default config.

Using modernizr

By default a modernizr custom build is generated with setclasses option and can be imported via

import Modernizr from 'modernizr'; // as named import
import 'modernizr'; // direct import

To extend the configuration and add tests and feature detections, create a .modernizrrc in your Project Root:

module.exports = {
  "feature-detects": [
    "test/css/flexbox",
    "test/es6/promises",
    "test/serviceworker"
  ]
};

See full configuration possibilities

Usage in standalone projects

The scripts are designed to work with a Neos or Typo3 folder structure, for the most parts it is also possible to use them in other projects. Therefore you have to define your base- and site-package as . in your package.json

{
  "basePackageName": ".",
  "sitePackageName": "."
}

Additionally you have to turn off the icon sprite generator, because it relies on a specific place, where the icons are stored. E.g. in your package.json.

  "scripts": {
    "build": "npm run webpack --noIconSprite",
  },

Also, you might want to change the entry points and output paths via a custom webpack configuration (see above)

module.exports = function () {
  return {
    entry: {
      header: null,
      footer: null,
      main: "./src/index.js",
      print: null,
    },
    output: {
      path: './dist'
    },
  };
};

Testing

For unit testing create a file ${your-filename}.test.js within your javascript folder. Webpack will watch for files within the javascript directory ending on *.test.js. Run your tests by simply start npm run test.

If you want to test with the BDD approach, you can start the script with npm run test-watch. This will reload the tests with every save.

We use chai as assertion and sinon as mocking library. Within the testing environment you have access to the following global variables:

  • chai
  • sinon
  • expect - the chai.expect
  • assert - the chai.assert
  • sandbox - the sinon.sandbox

You can also use window and document, as usual.

Here you get more information about Sinon and Chai - BDD

Example:

// Resources/Private/Javscript/Custom/Component/ComponentToTest.test.js

/*global describe, it, beforeEach, afterEach, sandbox*/
import ComponentToTest from './ComponentToTest';

describe('ComponentToTest', () => {
  let component = null;
  beforeEach(done => {
    component = new ComponentToTest();
    // do some stuff before each testing step
    document.body.innerHTML = '<div id="myContainer"></<div>';
    done();
  });

  afterEach(done => {
    // do some stuff after each testing step
    document.body.innerHTMl = '';
    done();
  });

    describe('some tests with special attributes', () => {
      it('it should do something', done => {
        // do something with <component>
        component.initialize();

        // do some expectations concerning <component>.
        expect(component).to.have.property('initialized').equals(true);
        done();
      });
    });
  }
}

Release a new version:

Pre-releases

To create a pre-release one can push/merge changes to branch next. This triggers actions to automatically create a pre-release. Use @next as version in your project package.json to use the current pre-release.

Releases

  1. Merge your branch/changes into main branch
  2. Bump version in package.json with npm version [<newversion> | major | minor | patch
  3. Push bumped version including new tag to main branch with git push --tags
  4. Create a new release with release notes from newly created tag on github
  5. The new release will trigger GitHub Actions for automatically publishing to NPM

FAQs

Package last updated on 20 Oct 2022

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc