Let's see if we can start a synergy with StartBootstrap StartBootstrap/startbootstrap-clean-blog#138
2 replies
Oh, I think that's fine. It saves you from the headache was it ../ or ../../ or ...
Looking at JS Maps, they would probably provide a better DX for v3 for the Files object.
Then you could add/ remove files like
Then you could add/ remove files like
files.set('some/file.html', { contents: Buffer.from('Hello') })
files.get('some/file.html')
files.delete('some/file.html')
files.values() // get all file objects
files.keys() // get all file paths
files.entries() // get all files as [key, path]
Oh, interesting.
Maybe there could be a compatibility layer indeed. Maybe there could even be some sort of versioning scheme for plugins so old ones don't immediately break, but new ones can make native use of new data structures. Either way, the overhead needs to be considered and it should stay as small as possible, obviously.
Maybe there could be a compatibility layer indeed. Maybe there could even be some sort of versioning scheme for plugins so old ones don't immediately break, but new ones can make native use of new data structures. Either way, the overhead needs to be considered and it should stay as small as possible, obviously.
I meant in a way that multiple restructuring/remapping/... operations could be a performance hit at some point, the more files and the more plugins the more significant.
Well, that's the issue. To prevent that, there'd need to be some compatibility layer or plugin versioning. And that overhead might be a (small enough) performance hit.
Reminds me of the Drupal vs Wordpress adoption. Drupal introduced major breaking changes with every major version release, Wordpress always maintained backwards compatibility. Drupal’s adoption rate went down after every major version change, people switch to Wordpress.
I agree somehow, but on the other hand, now are many plugins already quite outdated and due to a refresh (although they might still work, but no updated dependencies in years is just ugh).
Good point @qg but I believe MS needs to project stability at this point.
Best would be not to break existing plugins anytime soon indeed. Maybe there could be some sort of
.useV2 coexisting with .use, which makes restructuring of data with all it's overhead only necessary if they are in direct succession:.use(...).use(...)and.useV2(...).useV2(...)with no overhead.use(...).useV2(...).use(...)with two times overhead.use(...).use(...).useV2(...).useV2(...)with one time overhead
Of course this should rather be hidden away at best so each plugin can define its version somehow itself and not depending on how it is called.
Sure, it would add overhead, but it might be worth it to introduce new things at some point without breaking the old plugins.
It's doing pretty well right now anyway:
Meh! did a quick test and metalsmith (core, not plugins) actually works with Deno when you run it like
deno run --compat --unstable --allow-read --allow-env metalsmith.js
Working on powerful
requests plugin:metalsmith(__dirname)
.use(
requests([
{
url: 'https://api.github.com/repos/metalsmith/:repo/contents/README.md',
out: { path: 'docs/core-plugins/metalsmith-:repo.md' },
with: [
{ repo: 'layouts' },
{ repo: 'permalinks' },
{ repo: 'remove' }
],
options: {
auth: 'metalsmith:fakeToken3EK3rZErklazr33526',
headers: {
'Accept': 'application/vnd.github.3.raw'
}
}
}
])
)
@webketje That said, you're certainly correct that debugUi does some unorthodox (hacky) things patching the ms build fn to get the snapshots. If you have plans for a plugin to generate snapshots, then as you said it would be best for debugUi to use that internally. So if I were to publish a new version it would probably be best to wait until after that.
@leviwheatcroft It is freaking awesome (just like metalsmith)! I used it recently for debugging the metalsmith.io website, and it also inspired me for an idea for a CMS frontend (generating a folder at eg
After nearly 2 years of dialogue with the other lead maintainers (Ismay & woodyg) & Segment we finally got ownership & going full speed since December 2021 (NPM downloads for the latest versions reached half of what 2.3.0 had in 5 years in only a month). So it's not too late too come back ;)
/ms-admin). It's not for now yet, but I have the ambition to bridge the gap between expensive headless CMS & non-user-friendly static site generation.After nearly 2 years of dialogue with the other lead maintainers (Ismay & woodyg) & Segment we finally got ownership & going full speed since December 2021 (NPM downloads for the latest versions reached half of what 2.3.0 had in 5 years in only a month). So it's not too late too come back ;)
I wrote about a responsive/progressive image component for Metalsmith. The component is build with Nunjucks but the principle can easily be used for other template languages as well. Makes the use of responsive images very easy.
I published a set of Starters, from a bare-bone for someone who is just starting to a company starter with flexible page layouts. The flexible layouts starter is also discussed in a new blogpost https://www.glinka.co/blog/building-flexible-page-layouts/. Finally, since metalsmith-assets is dead I build a new plugin https://github.com/wernerglinka/metalsmith-static that does the same but is up-to-date.
I'll be updating the awesome metalsmith part of metalsmith.io soon. Please let me know if you have anything, blogposts, starters, plugins that should be listed there.
Ugh I'm really pulling my hair out about this one, feedback welcome.
So I'm hesitating how to make the debug & log features available keeping the API footprint as small as possible for 2.5.
The primary feature is ofc that a plugin can do const debug = metalsmith.debug('metalsmith-myplugin'); debug('sth'); debug.warn('warning').
But the tricky part is the debug log. it requires a NodeJS writestream (which needs to be ended after all plugins have run, so it cannot be implemented by a plugin).
Additionally, 2.5 will provide the convenience that env vars don't need to be specified on the command-line (eg, debug can be toggled by doing metalsmith.env('DEBUG', true), NB: this will also help clean up plugin readme's Debug section, as it's canonical for Windows & Linux). My concerns are:
- How is a user supposed to enable/disable the log? Options are, 1) through a dedicated env var
metalsmith.env('DEBUG_LOG', true), 2) depending on the value ofmetalsmith.env('NAME') // or NODE_ENV(log when !== 'production'). - Where should the log be generated? in the working dir or the build? Do users need to be able to control the location of the log file? ATM I'm leaning towards the working dir as it's not really part of the build.
I don't want to add a metalsmith.log function as it would be confusing/ overlap with metalsmith.debug/ env functionality
Yesterday the product owner wrote Metalsmith as a technical solution in a spec document. If this works out, I could work on bringing together the best of static site generators together with a Node Express backend and a front-end framework. I want to prove how valuable this approach can be compared to "holistic" SSGs like NuxtJs which encourage you to mix everything (front and backend logic, i18n, etc).
This would provide an exciting opportunity to work on plugins (multilingual) and also a setup where part of the site is only accessible as authenticated user
Info: On May 3rd, Jon Kulton wrote an article about https://httpstatuses.io (a useful site which lists all HTTP status codes) and mentioned his fork was built with Metalsmith. This produced a 250% spike in traffic!