Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/pkgsite: improve frontend development ergonomics #40960

Open
andybons opened this issue Aug 21, 2020 · 2 comments
Open

x/pkgsite: improve frontend development ergonomics #40960

andybons opened this issue Aug 21, 2020 · 2 comments

Comments

@andybons
Copy link
Member

@andybons andybons commented Aug 21, 2020

There are multiple items likely associated with these improvements, so it may make sense to break them out and label this an umbrella issue.

  • A JS style guide (to complement https://golang.org/wiki/CSSStyleGuide) is needed to guide contributors through best practices when developing on frontend.
  • It’s not clear that the JS compiler is providing a ton of value, as it takes a very long time to compile and we don’t have much JS to serve. A minifier written in Go (and therefore easily embeddable) could be used (https://github.com/tdewolff/minify is one such minifier with one major issue: it does not generate source maps).
  • When developing locally, a separate compile step should not be needed to have the changes be served. We could serve the files individually and uncompiled, or serve a minified version with a source map.
  • Each page should only have the assets that it needs and nothing more. We serve a lot of unused CSS on pages that don’t need it.
  • Given our browser support matrix and the user agents visiting us, it may make sense to migrate fully to JavaScript Modules (<script type="module">) so that older, unsupported browsers don’t attempt to load our JS and barf in our error logs.
  • A mechanism to easily test pages with no JS at all. This would help keep us honest for when someone has JS disabled (are we doing our best to provide a degraded but functional experience?)
  • A testing methodology. Do we pull in Jest or run our own tests using Russ’ webdriver package?

I’m sure we can come up with bundling functionality using Go that gets us most of the way there without needing to pull in third-party tooling that requires NPM. Testing is another story, so we’ll have to figure out where we draw the line on whether to pull in NPM or not for that.

@tooolbox
Copy link

@tooolbox tooolbox commented Aug 21, 2020

In case it's useful, esbuild is a Go bundler that could even be used as a library to serve JS on the fly. Doesn't have full ES5 support but if you're talking about using <script type="module"> perhaps it's an option for pulling NPM out of the equation.

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 2, 2020

Change https://golang.org/cl/252823 mentions this issue: cmd,content,internal: create a flag to disable CSP

gopherbot pushed a commit to golang/pkgsite that referenced this issue Sep 15, 2020
Adds a flag to disable CSP during local development.
Useful for debugging Google Tag Manager configuration.
Does not cause security risk because its only for local
development and you can't use runtime flags in App Engine.

For golang/go#40960
For golang/go#40958

Change-Id: I9669bd745d1bb3f78472d91142053992dde2cc6b
Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/252823
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Trust: Julie Qiu <julie@golang.org>
@gopherbot gopherbot added the go.dev label Sep 18, 2020
@julieqiu julieqiu removed the go.dev label Sep 19, 2020
@gopherbot gopherbot added the go.dev label Sep 19, 2020
@julieqiu julieqiu removed the go.dev label Sep 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.