Replace polymer-cli with alternative build/serve/test tools

[keanulee]

The current version of polymer-cli has some baggage (lodash 3, bower-json) that introduces low and moderate npm audit vulnerabilities to this repo. Conceptually it would be possible to replace the build step with scripts (e.g. in gulpfile) using polymer-build, serving with polyserve, and testing with some other test runner/launcher/aggregator.

From https://github.com/Polymer/pwa-starter-kit/issues/336#issuecomment-463736822

[jsilvermist]

Doesn't it make more sense to just create a breaking version of polymer-cli without lodash, etc?

[ghost]

I agree with @jsilvermist that refactoring a version bump or vanilla replacement would seem the intuitive course of action. Thank you very much for your response @keanulee.

[ghost]

I wonder if the fact the repository I'm linking to is archived should be worrying but https://github.com/lodash-archive/lodash-migrate perhaps this task can be automated with the assistance of this utility.

I'm going to attempt a version bump into 4+ aswell as the stacky dependancy and I'll touch back if I can accomplish this first.

Is this the source of stacky https://github.com/googlearchive/stacky the readmes seem to match. Was this utility replaced or simply dropped for ongoing maintenance? Is there still a means of updating it upstream besides taking it on as a fork?

[ghost]

I'v taken some time to refactor and get to know the stacky project, (chalk can be replaced easily aswell in vanilla js) it doesn't seem to require any dependancys whatsoever from the standpoint of an importer so including them really gets under my skin. There are also some very simple improvements that can be made to breath life into it. Is there any way to communicate with the maintainer over it regarding its tooling since they are sorely outdated and raising red flags for those that might want to checkout polymer? The issue board is inaccessible and its branded heavily with the polymer name so responsibility must fall on someone here?

There seems to be quite a bit of spring cleaning to do.

[silenceisgolden]

It would be lovely to see an effort similar to react-scripts implemented here but using tools that are more adopted already by the community. https://github.com/open-wc could potentially head in that direction and there are several third party repos that offer ready-made project setups as well.

[keanulee]

For reference, I'm going to leave a link to the very much WIP no-cli branch where I was working on replacing the build step.

[mercmobily]

Is the plan to actually dismantle polymer-cli in the longer term? I am probably a lone wolf here, but I love the simplicity of the Polymer CLI, which -- to date, at least for me -- has been the only thing that has always "just worked".

Call me lazy...

[ghost]

Atleast with stacky, it just needed to be updated. My confusion is how/who to make that happen considering its an archived dependency.

[motss]

Is the plan to actually dismantle polymer-cli in the longer term? I am probably a lone wolf here, but I love the simplicity of the Polymer CLI, which -- to date, at least for me -- has been the only thing that has always "just worked".

Call me lazy...

@mercmobily Couldn't agree more on that. At least I guess you are not the only one who think like that. Not sure what the future of Polymer CLI holds. It's been unmaintained for so long (just look at all those outdated dependencies with security warnings!).

[mercmobily]

@motss I didn't think it was abandoned. It's not going through super-active development, but the changelog confirms that it is getting some love...

[kr05]

Recently (past month), I started encountering nasty out of memory errors in my builds. Do you have any insight as to what might be causing them? I found this thread looking for a replacement to polymer-cli due to these errors that I haven't been able to fix, but I would definitely prefer to keep using it. As @mercmobily put it very nicely, I love the simplicity of polymer-cli.

[rwestlund]

@kr05 I ran into that recently -- it went away after wiping and reinstalling node_modules. No idea what the cause was. If that doesn't do it, you can give node more memory with:

node --max-old-space-size=4096 ./node_modules/.bin/polymer build

I needed that trick to run the modulizer. These old polymer tools take ridiculous amounts of memory and time to build, but I'm struggling to find a replacement. Everything else either inserts its own module importer (instead of leaving it as es6 modules) or somehow breaks when run on PWA projects.

If anyone else knows of a simple tool that will rewrite imports, minify, bundle, and do nothing else, I'd like to hear about it.

[johnthad]

Maybe https://open-wc.org/ ?

[kr05]

I was able to get rollup + gulp working, and it doesn't appear to have any detrimental effects. On the contrary, it has drastically sped up build times. This is important to me, considering I use Google Cloud Build.

I have yet to explore all that rollup and gulp have to offer, but being able to deploy an update to my client's app was incredibly satisfying. If anyone is interested, I can post my rollup config file!

[mercmobily]

I would love to see it!

On Sun, Jul 7, 2019, 6:29 AM Kevin I Rivera notifications@github.com wrote:

I was able to get rollup + gulp working, and it doesn't appear to have any detrimental effects. On the contrary, it has drastically sped up build times. This is important to me, considering I use Google Cloud Build.

I have yet to explore all that rollup and gulp have to offer, but being able to deploy an update to my client's app was incredibly satisfying. If anyone is interested, I can post my rollup config file!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Polymer/pwa-starter-kit/issues/337?email_source=notifications&email_token=AAQHWXW7KKOXJM46RCKLABTP6EMFPA5CNFSM4GXQX6QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZLBIVY#issuecomment-508957783, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQHWXXRPPFXIPP6FOQCYHTP6EMFPANCNFSM4GXQX6QA .

[kr05]

rollup.config.json

import babel from 'rollup-plugin-babel';
import resolve from 'rollup-plugin-node-resolve';
import rimraf from 'rimraf';

rimraf.sync('build')

export default [{
  input: './src/my-app.js',
  output: [
    {
      dir: 'build/esm-bundled',
      format: 'esm'
    }
  ],
  plugins: [
    resolve({
      // use "jsnext:main" if possible
      // legacy field pointing to ES6 module in third-party libraries,
      // deprecated in favor of "pkg.module":
      // - see: https://github.com/rollup/rollup/wiki/pkg.module
      jsnext: true,  // Default: false
    })
  ]
},
{
  input: './src/my-app.js',
  output: [
    {
      dir: 'build/es5-bundled',
      format: 'system'
    }
  ],
  plugins: [
    resolve({
      // use "jsnext:main" if possible
      // legacy field pointing to ES6 module in third-party libraries,
      // deprecated in favor of "pkg.module":
      // - see: https://github.com/rollup/rollup/wiki/pkg.module
      jsnext: true,  // Default: false
    }),
    babel({
      "presets": [
        ["@babel/preset-env", {"targets": {"ie": "11"}}]
      ],
      "plugins": ["@babel/plugin-syntax-dynamic-import"]
    })
  ]
}];

gulpfile.js

const gulp = require('gulp');
const rename = require('gulp-rename');
const replace = require('gulp-replace');
const del = require('del');

/**
 * Cleans the prpl-server build in the server directory.
 */
gulp.task('prpl-server:clean', () => {
  return del('server/build');
});

/**
 * Copies the prpl-server build to the server directory while renaming the
 * node_modules directory so services like App Engine will upload it.
 */
gulp.task('prpl-server:build', () => {
  const pattern = 'node_modules';
  const replacement = 'node_assets';

  return gulp.src('build/**')
    .pipe(rename(((path) => {
      path.basename = path.basename.replace(pattern, replacement);
      path.dirname = path.dirname.replace(pattern, replacement);
    })))
    .pipe(replace(pattern, replacement))
    .pipe(gulp.dest('server/build'));
});

gulp.task('prpl-server', gulp.series(
  'prpl-server:clean',
  'prpl-server:build'
));

/**
 * Copies assets not handled by rollup into the public/ directory.
 */
gulp.task('rollup', () => {
  return gulp.src([
    'images/**',
    'node_modules/@webcomponents/webcomponentsjs/**',
    'index.html',
    'push-manifest.json',
    'manifest.json',
    'node_modules/regenerator-runtime/runtime.js',
    'node_modules/systemjs/dist/s.min.js'
  ], {base: '.'})
  .pipe(gulp.dest('build'));
});

The gulpfile is basically the same one that comes with the PWA Starter Kit, with the exception of the last step. In order to run it, I use the following commands:

rollup -c && gulp rollup && gulp prpl-server

[kr05]

Forgot to mention some changes in the index file. I was not able to find a good replacement for the base ref replacement polymer-cli offered. The alternative solution is the following client side check:

<script>
    import ('./esm-bundled/my-app.js');
window.supportsDynamicImport = true; 
</script> 

<script >
    function appendScript(src, cb) {
        const script = document.createElement('script');
        script.src = src;
        script.addEventListener('load', cb);
        document.head.appendChild(script);
    }
if (!window.supportsDynamicImport) {
    appendScript('node_modules/systemjs/dist/s.min.js', function () {
        appendScript('node_modules/regenerator-runtime/runtime.js', function () {
            appendScript('node_modules/@webcomponents/webcomponentsjs/custom-elements-es5-adapter.js', function () {
                System.import('./es5-bundled/my-app.js');
            });
        });
    });
} 
</script>

EDIT:
Excuse the bad formatting, I'm currently on my phone right now. Also, I would like to provide more context. This index file check is probably not the best solution, but it's what ended up working for me. If anyone has any suggestions to make it better, please let me know! This is all new territory for me. Hopefully someone finds this useful.

[rwestlund]

@johnthad Thanks for the open-wc recommendation. It took some doing, but I did get my app building with rollup and their default config. I used workbox to replace the service worker that polymer-cli was providing. The best part: my output bundle went from 2.4M to 1.2M! :smile:

[abdonrd]

@kr05 could you create PR to show all the changes to make it work? Thanks!

[abdonrd]

@keanulee @frankiefu there are any "official" updates? About no-cli, rollup & webpack branches. It seems that we are many people interested in using an alternative to the Polymer CLI.

Also related with Workbox adoption.

---

I'm personally interested in the rollup branch, but it:

• Breaks the npm start (because the index.html changes)
• It doesn't support the Polymer/prpl-server (because the new output files)
• It doesn't generate the Service Worker
• No push-manifest.json

[kr05]

@abdonrd I'll get right on it. The only thing I haven't implemented yet is Service Worker though...everything else is working as expected.

[mercmobily]

@abdonrd Oh my god you literally read my mind. I was going to write a message this morning listing exactly these four things: replacement for polymer serve with index.html changing on the fly, prpl-server changing the output files, push-manifest, plus I was going to add that this would be the PERFECT time to add support for BOTH Service Worker and Workbox!

These are the deal breaker that keep polymer-cli from being obsolete...

[kr05]

How can we verify that http/2 push is working as expected? Aside from deploying and checking the network tab, is there a method that can be used locally?

[logicalphase]

Aside from the protocol column in Chrome Dev Tools -> Network tab.

You can also install the chrome dev tool to inspect it quickly: https://chrome.google.com/webstore/detail/http2-and-spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin?hl=en

[kr05]

@abdonrd I just created the PR (#370). Sorry it took so long, I got caught up with work!

[mercmobily]

It's been 8 months... is there any movement in this department? The four points in this comment are very crucial. The convenience of "polymer-cli" is huge; being able to define one config file (polymer.json), shared by the PRPL server and polimer-cli) is really precious. However, the memory problems and the lack if a good solution for changing base in index, along with failing npm audit, are a worry.

Am I the only one who would like to actually keep polimer-cli, in such a way that doesn't fail audit and doesn't use huge amounts of memory and time to build?

[kr05]

@mercmobily I still use polymer-cli on smaller projects. I haven't been able to wean myself completely from it, unfortunately. The fact is...when it works, it's one of the best tools ever.

[johnthad]

Last April I switched to Open-WC (https://open-wc.org/). No regrets. Flexible, up-to-date, and well managed.

[mercmobily]

@johnthad So...

• What do you use instead of polymer serve?
• How do you build your app, changing base?
• Do you use the PRPL server?

[johnthad]

@mercmobily

• es-dev-server (https://www.npmjs.com/package/es-dev-server), which is maintained by the @OpenWc team. Excellent. It also handles hot loads and HTTP/2. • npm init @open-wc will set up es-dev-server, and several build scripts. Running npm run build creates a dist directory that I drop into Apache HTTP 2.4 (the open-wc docs discuss netlify). I've little experience with JavaScript build tooling, and but their stuff is understandable (like tweaking their Rollup script). • Much of my project structure is lifted from the PWA Starter Kit and its pwa-helpers. I use the same Redux state management tooling. The Books app was a great help in understanding this (or at least mimicking it).

The @OpenWC team has been very helpful. You can reach out to them on Polymer Slack and Twitter.

[stale[bot]]

This project is no longer under development and will be transitioning to a read-only repo. Thank you for your contributions.