Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 02 16:30

    depfu[bot] on update

    (compare)

  • Dec 02 16:30
    depfu[bot] closed #841
  • Dec 02 16:30
    depfu[bot] commented #841
  • Dec 02 16:30
    depfu[bot] labeled #842
  • Dec 02 16:30
    depfu[bot] opened #842
  • Dec 02 15:27

    depfu[bot] on update

    Update jest to version 27.4.3 (compare)

  • Dec 01 15:25

    depfu[bot] on update

    (compare)

  • Dec 01 15:25
    depfu[bot] closed #832
  • Dec 01 15:25
    depfu[bot] commented #832
  • Dec 01 15:25
    depfu[bot] labeled #841
  • Dec 01 15:25
    depfu[bot] opened #841
  • Dec 01 14:23

    depfu[bot] on update

    Update jest to version 27.4.2 (compare)

  • Nov 28 21:31
    depfu[bot] synchronize #822
  • Nov 28 21:31

    depfu[bot] on update

    Update offline-github-changelog… (compare)

  • Nov 28 20:24
    depfu[bot] edited #822
  • Nov 28 20:22

    depfu[bot] on update

    (compare)

  • Nov 28 20:20
    papandreou closed #840
  • Nov 28 20:20

    papandreou on master

    Update prettier to version 2.5.0 Merge pull request #840 from un… (compare)

  • Nov 28 05:41
    shicks commented #525
  • Nov 26 21:35
    depfu[bot] labeled #840
Gustav Nikolaj
@gustavnikolaj
Autoprefixer is nice, but since we got to up our browser support baseline to ESM capable browsers, I don't think it makes too much sense :)
Peter Müller
@Munter
It's a thing that just makes CSS go
Gustav Nikolaj
@gustavnikolaj
It made much more sense when you had to do a bunch of vendor prefixes all the time for mundane things, but I think it's less relevant these days. I'd honestly rather live without bleeding edge features in CSS and not having to have a tool to preprocess my css
Same goes for babel/javascript
But I've lost the vote on babel / jsx :D
Sune Simonsen
@sunesimonsen
I agree
Peter Müller
@Munter
Then what tool do you use to keep CSS discipline? Does every developer know the support level of every css property and your browser usage by heart?
Sune Simonsen
@sunesimonsen
@gustavnikolaj I'm taking notes, because you sounds like my first customer of depository view ;-) :joy:
Gustav Nikolaj
@gustavnikolaj
@Munter I get your point. It's certainly a problem that we have. People tend to be pretty good at it - honestly I don't remember the last time we had a problem from that.
But we don't have any mitigating factors in place
Peter Müller
@Munter
Like, I'd love to use flex gap. And it looks Sooo green on caniuse. But do I remember which Safari major/minor versions I need to support?
Gustav Nikolaj
@gustavnikolaj
apart from code review, qa etc
Using autoprefixer will solve that for you, and I actually do use just that, so I'll yield that point to you ;)
Sune Simonsen
@sunesimonsen
Safari users don't deserve gaps :joy:
Peter Müller
@Munter
tight...
Gustav Nikolaj
@gustavnikolaj
But I think the overall principle still stand. I'm willing to accept a non-zero amount of production facing issues like that, if it means that my tool chain will be that much simpler
Sune Simonsen
@sunesimonsen
The version I have installed supports gaps :sweat_smile:
Peter Müller
@Munter
I think at this point that's fair. And I was actually being a bit of a devils advocate there, because what we do right now is exactly what you describe. However I run a fast moving single product in a growth phase. I don't maintain 30+ webapps that need a consistent behavior
Sune Simonsen
@sunesimonsen
Nicely played :D
Gustav Nikolaj
@gustavnikolaj
!! :)
I have the other situtation you describe, with many different, but slightly similar, applications. I haven't found a way that I'm comfortable with, to manage them all without tooling overhead. So my coping mechanism is to keep things simple
If a setup breaks in some app I can blast away the bundler, test runner etc, and have things up and running again within 15 minutes. That's only possible because we shy away from as much custom stuff as possible
About the only custom thing we do is to import stylesheets from js
but most bundlers support that
Sune Simonsen
@sunesimonsen

If a setup breaks in some app I can blast away the bundler, test runner etc, and have things up and running again within 15 minutes. That's only possible because we shy away from as much custom stuff as possible

Exactly

Gustav Nikolaj
@gustavnikolaj
I actually considered adding a rule to my eslint setup, requiring that you put the .js-extension imports to close the gap towards browser-based esm
I think people will get annoyed with me, but it seems like a good idea to me. We will have to start doing that eventually, and it will make it easier to get things working without a build-step
Andreas Lind
@papandreou
With a bit of luck they'll just yell at eslint :)
Peter Müller
@Munter
It's not too hard to create a fix rule, so you can have eslint autofix it for you ;)
Andreas Lind
@papandreou
Yeah, it's a good way to turn your opinions into law :)
Gustav Nikolaj
@gustavnikolaj
For all the talk about keeping things default and avoiding custom stuff like the plague.....
Do you guys have any experience with alternatives to require.context in webpack? I'd like a way to glob all files matching a specific pattern, and then use import to code-split each of them into their own bundle. If I use require.context I'll just end up with all in the same bundle
Or without webpack?
Gustav Nikolaj
@gustavnikolaj
Yeah, but I need to be able to have a glob pattern across subfolders. Webpack only is fine
Andreas Lind
@papandreou
I remember having fought that at some point, and also helped implement the equivalent thing in the assetgraph system.js integration, so I can at least say that it's hairy! But I don't know off the top of my mind.
Gustav Nikolaj
@gustavnikolaj
Yeah, you need to plugin in a pretty early phase. I don't think it's possible without a custom plugin at this point. At least not if you want to be able to have bundle barriers at those points
Gustav Nikolaj
@gustavnikolaj
The easy, non webpack specific fix, is to just have a pre-start script that will build a js file with a bunch of paths in an array that I can import :)
Andreas Lind
@papandreou
If there's no bundle splitting etc. required, yeah
Gustav Nikolaj
@gustavnikolaj
Right, I'd need to actually generate the code from the list of values.

export default {
  "./path/to/file.js": () => import('./path/to/file.js'),
  // ...
}
Andreas Lind
@papandreou
Ah
Gustav Nikolaj
@gustavnikolaj
The main drawback is that you'd have to restart webpack for it to pick up on new matches
Andreas Lind
@papandreou
That's a nice low-tech way to do it if that stuff doesn't change all the time
I wonder if you also need to "memoize" the imports to avoid re-importing, or if the browser has a module cache.
Gustav Nikolaj
@gustavnikolaj
what would the browsers module cache do here? isn't it translated to webpacks bundle format?
or are you talking in the non-webpack case?
Andreas Lind
@papandreou
Ah, right, webpack's loader will handle it
But yeah, also the non-webpack case. I'm revealing my agenda of having the dev setup work without a bundler ;)
Gustav Nikolaj
@gustavnikolaj
I'm almost a little ashamed to admit, but what I'm doing is a reimplementation of react storybook. :p I got sick and tired with upgrading the real one. It's such a simple tool but they manage to make it progressively worse and worse.
Andreas Lind
@papandreou
Sounds like you should just have stayed on the old version :)