Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Andreas Lind
@papandreou
If there's value in doing this stuff lazily, we could also consider making isPretty a getter.
Which test is that?
Peter Müller
@Munter
  1) transforms/bundleRelations
       with the oneBundlePerIncludingAsset strategy
         should insert a JS bundle at the point of the last incoming relation:
     UnexpectedError:
expected [ Html(testdata/transforms/bundleRelations/insertPoint/HtmlScript.html) ] to satisfy
[
  {
    type: 'Html',
    text: '\n<h1>Hello World</h1>\n<script>var foo = \'foo\';\nvar bar = \'bar\';</script>\n'
  }
]

[
  Html({
    type: 'Html',
    url: 'file:///Users/munter/git/assetgraph/testdata/transforms/bundleRelations/insertPoint/HtmlScript.html',
    isLoaded: true,
    isInline: false,
    isRedirect: false
    text: '\n<h1>Hello World</h1>\n<script>var foo=\'foo\';var bar=\'bar\'</script>\n'
          // should equal '\n<h1>Hello World</h1>\n<script>var foo = \'foo\';\nvar bar = \'bar\';</script>\n'
          //
          //
          // <h1>Hello World</h1>
          // <script>var foo='foo';var bar='bar'</script>
          // <script>var foo = 'foo';
          // var bar = 'bar';</script>
  })
]

      at Context.<anonymous> (test/transforms/bundleRelations.js:143:7)
      set UNEXPECTED_FULL_TRACE=true to see the full stack trace
Andreas Lind
@papandreou
That might be the isPretty: undefined case kicking in maybe?
(I mean before)
Peter Müller
@Munter
Parsetrees are read before that, so isPretty should be explicitly defined at that point
yup.
{
  url: undefined,
  text: "var foo = 'foo'",
  isPretty: false,
  matches: null
}
{
  url: undefined,
  text: "var bar = 'bar'",
  isPretty: false,
  matches: null
}
If isPretty was undefined at that point before, isPretty of the bundle would have been false I guess
Peter Müller
@Munter

Ah, except, this is the current code in bundleRelations:

        _toBeMinified: assetsToBundle.every(asset => asset._toBeMinified),
        isPretty: assetsToBundle.every(asset => asset.isPretty)

and the current code to check if the pretty formatting should be applied is this.isPretty || !this._toBeMinified

If I'm reading that right, any bundle produced would always be pretty printed at serialization time, unless there had been an explicit call to bundleAsset.minify()
Andreas Lind
@papandreou
That sounds right. And in ag-b there always will be
I have to drop offline soon
Peter Müller
@Munter
np, just thinking aloud a bit :)
I'll update the test
Andreas Lind
@papandreou
Netlify edge handlers, huh? Sounds like a familiar idea.
Peter Müller
@Munter
Yu watching jamstack conf stuff?
Andreas Lind
@papandreou
No, I received an email. Is something interesting on?
Peter Müller
@Munter
They're on break right now. Toast.dev is going to be interesting
I missed the keynote
Some of the stuff is up already. https://www.youtube.com/watch?v=j2C0SIJFlv8
Andreas Lind
@papandreou
Ah cool, I was just signing up for it like an idiot :)
Peter Müller
@Munter
:fishing_pole_and_fish:
I had a little chat with the imgix people and got a $300 voucher for their service. Our usage of heavy imagery might need an image cdn soon
Andreas Lind
@papandreou
🤑
Andreas Lind
@papandreou
Btw. I made a transform that uses rollup to bundle JavaScript: https://github.com/assetgraph/assetgraph-rollup
Thinking about making it a "full" integration with support for rollup.config.js. Thoughts?
Peter Müller
@Munter
Sounds like a good idea. I did a bit of work with reading in the config when i switched mocha to rollup. The problems area always the same as with any other bundler; well need to figure out how to extend the existing config without breaking it. But that seems a while lot easier with rollup than with webpack
Andreas Lind
@papandreou
My impression so far: Hell yes!
But the feature set/scope of rollup is also way smaller (which I think is good)
Peter Müller
@Munter
Andreas Lind
@papandreou
Nice, thanks! :heart:
Must be one of the only libraries with ~20K stars that hasn't released a 1.0.0 yet :laughing:
Andreas Lind
@papandreou
:muscle:
Gustav Nikolaj
@gustavnikolaj

Hi guys. <3 I have a quick question - I couldn't find an answer myself from reading the source but I think you'll prob know straight away.

I have a static site I'd like to build with assetgraph-builder. It has quite a few broken relations - from links like <a href="/foo/bar"> meant to target ${root}/foo/bar.html. The files are going to be served by an nginx with the following config try_files $uri $uri.html $uri/index.html;.

Is there anyway to teach assetgraph to attempt to resolve a dangling relation by adding .html to an extension-less URL, without patching the code?

Andreas Lind
@papandreou
Not presently, but probably in 7.0.0 where I hope that these resolvers and loaders can move to plugins.
Gustav Nikolaj
@gustavnikolaj
Cool :-) I will just use find to list all my entrypoints and ignore the warnings for now. :-)
Andreas Lind
@papandreou
hyperlink has a --pretty switch that implements roughly that, but it's not directly portable.
7.0.0 probably won't be out for some time, as usual we have a lot of ambitions and very little time :)
Gustav Nikolaj
@gustavnikolaj
hehe :) That's fine. As long as there's something on the horizon I'm fine with things not being perfect.
Andreas Lind
@papandreou
:ok_hand:
Gustav Nikolaj
@gustavnikolaj
If I get impatient I'll just have to throw some volunteering hours at you ;-)
Andreas Lind
@papandreou
It's certainly possible to implement, given that we already support mapping foo => foo/index.html for file: urls.
Gustav Nikolaj
@gustavnikolaj
Yeah, I noticed that :-)
We're working on a staticly generated version of the one.com storefront
They're very particular about URL stability - so changing /foo/bar to /foo/bar/ is not going to fly unfortunately.
That'd make a lot of things a whole lot easier though :)
Andreas Lind
@papandreou
Cool!
It's probably a matter of exploring a few more options here: https://github.com/assetgraph/assetgraph/blob/master/lib/assets/Asset.js#L388-L395
And then also avoiding the addition of .html when refreshing an incoming relation like the hack for index.html here: https://github.com/assetgraph/assetgraph/blob/73afa2f66326e66d7f24141bf577df0a1b8e6162/lib/relations/Relation.js#L163-L169
But it'd be nice to move it to a plugin.
Gustav Nikolaj
@gustavnikolaj
It'd be a better fit for a plugin for sure. I don't think we can land it as default behaviour (at least not without thinking really hard about it) and it seems like an oddly specific thing to land in core.
Andreas Lind
@papandreou
We're already pretty far down that path with index.html, so it might be fine. I don't think there's be much ambiguity, as we'd only map foo to foo.html if there's no exact match (and no foo/index.html I guess, but we can discuss the precedence order)
Gustav Nikolaj
@gustavnikolaj
yeah I suppose. But OTOH index.html resolving is something almost any webserver will do. The same is not true for /foo => /foo.html
Andreas Lind
@papandreou
Yeah, I guess there are use cases where throwing an error is the right thing for assetgraph.