Can't install / list building blocks

[lundmorten]

Foundation cli version 2.2.5

Running foundation blocks list
results in "error fetching file /building-blocks/data/building-blocks.json" ...

The same with foundation blocks install [some block]

[DanielRuf]

Hi @lundmorten,

thanks for reporting this.

It seems we have to change it to get.foundation.

foundation-cli/lib/commands/blocks.js

Line 25 in 731c0df

fetchUrl('foundation.zurb.com', '/building-blocks/data/building-blocks.json', function(blocksJson) {

https://get.foundation/building-blocks/data/building-blocks.json

[DanielRuf]

@joeworkman It seems I do not have any rights on npmjs to publish a new release. Can you do that? Don't forget to increment it (patch version).

[DanielRuf]

Also ZURB should check the redirect: foundation.zurb.com/building-blocks/data/building-blocks.json doesn't load / redirect at all.

[joeworkman]

This issue has been mentioned on Foundation Open Source Community. There might be relevant details there:

https://foundation.discourse.group/t/building-blocks-error-using-cli-install/1361/2

[HansUXdev]

So this is sorta a big issue and I just double checked and it's still an issue.
The CLI is getting old and the community may need to evaluate whether or not its worth maintaining / replacing.
Personally, I think its the best part of the entire foundation framework and I've been maintaining my own fork for about 2 years now so I'm willing to dedicate a lot of time to making this run smooth again but I definitely can't do it alone.

The main issue right now as far as I can tell is that fetchUrl() function is returning an invalid url and the user isn't receiving the files they are making a request for. So my questions are:

• are we waiting on zurb to make the required redirects?
• was the dns and domain change really worth all these breaking changes?
  I mean honestly, all for a damn gimmick .foundation domain?
• If we are going to stick with the gimmick, can we implement a fallback in the mean time so that if the request fails, it asks to download as a zip?
• what about scoped packages / monorepo for the long term?
  The idea being that we just grab the files from the building-block git.
  example @foundation/marketing-kit || @foundation/block-type-sidelines

Finally, I have a question on performance. Wouldn't it make more sense if we cached the foundation blocks and copied them from the cache into the project folder? Right now, the architecture makes the CLI read the directory, checks if there is src/, and either downloads a zip via a network request or makes a network request for the files, processes them as a stream and then writes them to the drive.

Network request & R/W IO is always going to be the biggest bottleneck and we use both of them.. It just seems like it would be more efficient to stick with read/write & copy and avoid the network request all together, unless we have to.

But if I'm wrong on that, do correct me...

[DanielRuf]

• we waiting on zurb to make the required redirects?

Probably not, and if it would take very long. We have a direct ZURB contact but the communication is not that easy.

We have already some redirects regarding the forum and website but not for these. When we make a new release and people update the CLI it should work again.

[DanielRuf]

• can we implement a fallback in the mean time so that if the request fails, it asks to download as a zip?

Probably not that feasible. People can run npm i foundation/foundation-cli to install directly the latest version from the repository using Git.

I have already updated the affected files, this is not a problem. But I have no permissions on npm afaik.

0cd91f0

cc @joeworkman

[DanielRuf]

• what about scoped packages / monorepo?

Planned vor v7. See foundation/foundation-sites#11847 and other related issues.

[DanielRuf]

Finally, I have a question on performance. Wouldn't it make more sense if we cached the foundation blocks and copied them from the cache into the project folder? Right now, the architecture makes the CLI read the directory, checks if there is src/, and either downloads a zip via a network request or makes a network request for the files, processes them as a stream and then writes them to the drive.

Not sure how we can check when we have to refetch. Normally we would need some hashes. CLI is not browsers so there are no native caches. And when we update the building blocks the latest avilable version should be fetched.

[DanielRuf]

Network request & R/W IO is always going to be the biggest bottleneck and we use both of them.. It just seems like it would be more efficient to stick with read/write & copy and avoid the network request all together, unless we have to.

I would not bundle them with the CLI as this would produce a pretty big cli package. Only ship what people need (the commands).

[HansUXdev]

Network request & R/W IO is always going to be the biggest bottleneck and we use both of them.. It just seems like it would be more efficient to stick with read/write & copy and avoid the network request all together, unless we have to.

I would not bundle them with the CLI as this would produce a pretty big cli package. Only ship what people need (the commands).

I wasn't suggesting that because your right, its large enough as is.

@DanielRuf What are your thoughts on a vscode extension as a more modern alternative?
I've made some simple ones already and have been thinking about this for awhile.

If you check out the mjml vscode extension and the way they fetch templates is probably a lot faster and more efficient than the current way. Instead of templates, we could just request some json in the building blocks repo for the list?

[DanielRuf]

What are your thoughts on a vscode extension as a more modern alternative?

Not everyone uses VSCode (at least I use VSCode), many use WebStorm, PhpStorm, Coda or other solutions. Makes not much sense to support only one IDE.

[DanielRuf]

we could just request some json in the building blocks repo for the list?

This would break CLI installs as this is completely different then and requires more than a URL change.

Besides this, VSCOde extens are also Node packages so we get the same result like in the CLI.

In general: feels like yakshaving and too much effort for a small problem. Using npx is the recommended way in general.

[DanielRuf]

@joeworkman It seems I do not have any rights on npmjs to publish a new release. Can you do that? Don't forget to increment it (patch version).

[joeworkman]

Roger Roger.

[joeworkman]

I just released v2.2.6.