Make template.html and sw.js use publicPath by lwakefield · Pull Request #323 · preactjs/preact-cli

lwakefield · 2017-08-18T13:26:44Z

This PR aims to respect the use of webpack.output.publicPath and is intended as an alternative to #315.

HTMLWebpackPlugin handles injecting the rest of the resources, so that you can set output.publicPath and the generated index.html will reflect the change.

The intent here is to prefer customizability through the already exposed preact.config.js instead of adding new config/env flags.

I also propose that the following snippet be added to Config Recipes Wiki Page under the title "Specify the root url to serve from"

// preact.config.js
import { defineConstants } from '@webpack-blocks/webpack2';

export default function (config, env, helpers) {
  const PUBLIC_PATH = env.production ? '/my-gh-pages-url' : ''
  config.output.publicPath = PUBLIC_PATH
  config.plugins.push(defineConstants({ PUBLIC_PATH }))
}

reznord · 2017-08-18T15:48:14Z

There's already a PR for this. Just that it doesn't touch preact.config.js.

You can follow it on #315

lwakefield · 2017-08-18T15:53:26Z

Ah, my mistake @reznord! I'll close this in favour of #315

rodush · 2017-09-12T13:07:32Z

 		<meta name="mobile-web-app-capable" content="yes">
 		<meta name="apple-mobile-web-app-capable" content="yes">
-		<link rel="manifest" href="/manifest.json">
+		<link rel="manifest" href="<%= htmlWebpackPlugin.files.publicPath %>manifest.json">


For me it works right now -
<link rel="manifest" href="<%= __webpack_public_path__ %>manifest.json">,
why can't we use this?

I wanted to stay away from __webpack_public_path__ where possible. I think it is generally bad practice to be reading from that as it is mutable and not so reliavle. For lib/entry.js I used __webpack_public_path__ because it is the only available reference in the context.

I understand the inconsistency, but let me know what you think!

Yes, it is mutable, and this how webpack itself proposes to use this variable if the publicPath's value is not known at compilation time, so you can even set it in the entry point.

rodush · 2017-09-12T13:08:33Z

 else if ('serviceWorker' in navigator && location.protocol === 'https:') {
-	navigator.serviceWorker.register('/sw.js');
+	// eslint-disable-next-line no-undef
+	navigator.serviceWorker.register(__webpack_public_path__ + 'sw.js');


@developit Please take a look at this and decide finally about the solution. I really need this feature in my project :-)
In my opinion it is a nice solution, what are your concerns?

I'm fine with this, webpack will never change this var name and it keeps the resolution at runtime.

rodush · 2017-09-12T13:09:55Z

@lwakefield I don't understand, how the description of this PR correlates to the patch code?

lwakefield · 2017-09-14T20:17:30Z

@rodush I'm not fully sure I understand why you think the PR description doesn't relate to the patch code? Please feel free to suggest edits!

In the meantime, I have been using @lwakefield/preact-cli which has these changes. Maybe it can be of help, or you can create your own namespaced package?

rodush · 2017-09-14T20:29:07Z

@lwakefield I prefer not to get locked to custom fork unless it is 100% unavoidable 😉
Since this is quite young project, would be very nice to have this important option out of the box, that is why I'm hoping that the owner (@developit) will make a final decision.

lwakefield · 2017-09-14T20:33:24Z

I understand. Perhaps, you can branch yourself and change the package when this (or another PR) is merged?

rodush · 2017-09-14T20:52:26Z

@lwakefield here const PUBLIC_PATH = env.production ? '/my-gh-pages-url' : '' I would suggest '/' as default, otherwise you risk to have a relative urls ;-) that is what I was fighting with with an Angular build to be served from subfolder

rodush · 2017-09-28T07:49:19Z

@lwakefield any update on this? Any plans about merging this PR? @developit ?

lwakefield · 2017-09-28T16:02:49Z

@rodush, still waiting on review of either this or #315.

developit

This seems like the simplest approach to me. We'll need to consider processing manifest.json and rewriting its URLs, or noting for users that they must manually set their homepage URL there to the public path.

lukeed

Fine for now. Can optimize later on with the ideas we've all tossed around in this PR & in #315

* master: (166 commits) Use `publicPath` for SW & Manifest paths (#323) Purge `examples` dir (#393) Update Readme (#383) Add `preact list` command (#384) linters are dumb inject / replace strings in extracted contents adding flag to disable service worker Convert `css-loader` options to an Object (#349) remove `offline-plugin` (unused) remove `mkdirp` (unused) remove `less` dependencies fix linter move `htmlPlugin` to `render-html-plugin.js` install `css|postcss|style-loader` & regen `yarn.lock` remove `chunk.modules` deprecation notice rewrite server’s `webpack.config` without blocks rewrite client’s `webpack.config` without blocks install `webpack-merge` rewrite base `webpack.config` w/o blocks light refactor ... # Conflicts: # src/lib/webpack/webpack-base-config.js

tschnoelzer · 2018-02-02T15:53:14Z

Are there any updates on this? We need to use subdirectories for a couple of WebApps. I would love to use preact as we did lots of prototyping already. What is the latest idea to use subdirectories? I followed this tread and also the other related ones... not clear what is current state ....

imaitland · 2023-01-14T19:45:55Z

Did the recipe get added to the wiki?

I also propose that the following snippet be added to Config Recipes Wiki Page under the title "Specify the root url to serve from"

I see a test for this so assume it's the accepted way:
https://github.com/preactjs/preact-cli/blob/7d33cd1380b5dc7d4b4b970eceabfc8f126da1af/packages/cli/tests/subjects/public-path/preact.config.js

rschristian · 2023-01-14T19:50:06Z

A recipe was never added, no. but indeed, that's the way to alter the public path if you need to.

lwakefield closed this Aug 18, 2017

lwakefield mentioned this pull request Aug 18, 2017

Allow users to specify homepage variable in package.json #315

Closed

lwakefield changed the title ~~Make template.html use publicPath for manifest~~ Make template.html and sw.js use publicPath Aug 31, 2017

lwakefield reopened this Aug 31, 2017

lwakefield added 3 commits September 6, 2017 08:42

Make template.html use publicPath for manifest

a4516a8

Adds __webpack_public_path__ to registration of sw.js

a59e222

Disable eslint for __webpack_public_path__

5f5f0f8

lwakefield force-pushed the use-public-path-for-manifest branch from 4bd3de9 to 5f5f0f8 Compare September 6, 2017 12:43

rodush reviewed Sep 12, 2017

View reviewed changes

rodush approved these changes Sep 14, 2017

View reviewed changes

developit approved these changes Sep 28, 2017

View reviewed changes

Merge branch 'master' into use-public-path-for-manifest

ad67662

developit requested a review from lukeed September 28, 2017 19:34

lukeed approved these changes Oct 11, 2017

View reviewed changes

lukeed merged commit 52e9843 into preactjs:master Oct 11, 2017

developit mentioned this pull request Dec 7, 2017

Ability to remove leading "/" from built index.html src/href tags #437

Closed

florianmutter mentioned this pull request Jun 21, 2018

Service Worker loaded from CDN #591

Open

snyk-bot mentioned this pull request Apr 16, 2021

[Snyk] Security upgrade copy-webpack-plugin from 4.6.0 to 5.0.0 chagretes/preact-cli#15

Open

snyk-bot mentioned this pull request Aug 17, 2021

[Snyk] Security upgrade copy-webpack-plugin from 4.6.0 to 5.0.0 chagretes/preact-cli#18

Open

chagretes mentioned this pull request Nov 5, 2022

[Snyk] Fix for 1 vulnerabilities chagretes/preact-cli#33

Open

Uh oh!

Conversation

lwakefield commented Aug 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

reznord commented Aug 18, 2017

Uh oh!

lwakefield commented Aug 18, 2017

Uh oh!

rodush Sep 12, 2017

Choose a reason for hiding this comment

Uh oh!

lwakefield Sep 14, 2017

Choose a reason for hiding this comment

Uh oh!

rodush Sep 14, 2017

Choose a reason for hiding this comment

Uh oh!

rodush Sep 12, 2017

Choose a reason for hiding this comment

Uh oh!

developit Sep 28, 2017

Choose a reason for hiding this comment

Uh oh!

rodush commented Sep 12, 2017

Uh oh!

lwakefield commented Sep 14, 2017

Uh oh!

rodush commented Sep 14, 2017

Uh oh!

lwakefield commented Sep 14, 2017

Uh oh!

rodush commented Sep 14, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rodush commented Sep 28, 2017

Uh oh!

lwakefield commented Sep 28, 2017

Uh oh!

developit left a comment

Choose a reason for hiding this comment

Uh oh!

lukeed left a comment

Choose a reason for hiding this comment

Uh oh!

tschnoelzer commented Feb 2, 2018

Uh oh!

imaitland commented Jan 14, 2023

Uh oh!

rschristian commented Jan 14, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

lwakefield commented Aug 18, 2017 •

edited

Loading

rodush commented Sep 14, 2017 •

edited

Loading