menu

Gatsby.js

Fast in every way that matters. Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps.

Channels
# All channels
view-forward
# General
view-forward
# I Made This
view-forward
# Meta
view-forward
# Themes
view-forward
Team

plugin -> local to published: somethings breaking

February 17, 2020 at 12:12am

plugin -> local to published: somethings breaking

February 17, 2020 at 12:12am (Edited 2 months ago)
Hi there!
I just published a new source plugin (https://www.npmjs.com/package/gatsby-source-xkcd) and when I try to update my gatsby-config file to use it from the temporary local link using require.resolve:
{
resolve: require.resolve('../side_projects/gatsby-source-xkcd'),
},
to installing it via NPM and then referring to just the package:
{
resolve: 'gatsby-source-xkcd',
},
It seems to no longer be working? Wondering if it has to do with where files are placed in the plugin repo? When I was linking, it seemed like the gatsby-node file needed to be in the root, but looking at examples of other respositories, they were in a src directory.
Is this just a missing step on my configuration somewhere?
Any help is much appreciated! Cheers!

February 17, 2020 at 2:18am
First thing I'm noticing is that your distributed gatsby-node is importing a file from ./src/createNodeData and one from ./src/fetchNodesFromQueries. The src directory doesn't exist in the distributed package
Try running npm pack gatsby-source-xkcd, and then unpacking the tarball that gets downloaded. Check out the code there.
  • reply
  • like
What I like to do is write my source code in the src directory, and then the build dumps all of the transpiled (and otherwise processed) source into dist. All my gatsby-node.js does is module.exports = require('./dist/gatsby-node');. I use Typescript, too, which makes it pretty easy
I'm sure there's a lot of examples out there, but you can also check out this simple plugin I wrote to see what works for me.
  • reply
  • like
Oh, and btw, the gatsby-* files do need to be in the project root. Otherwise, Gatsby won't be able to find them.
  • reply
  • like

February 17, 2020 at 4:01pm
Thanks! I woke up this morning, decided to give it another shot, and immediately got the same error you're getting (last night, it ran fine, just didn't pull data...).
  • reply
  • like
-- The reason your data ends up in /dist is because of typescript, right? I'm happy to switch to TS, but any idea why my files are being moved around (just as a thought exercise)
  • reply
  • like
Yes, mine builds like that because of TS, but no, you don’t have to use it.
  • reply
  • like
Do you mean that you do, in fact, expect your files to be in src? I thought that through some processing phase, you had them being moved to the root.
Edited
  • reply
  • like
If I remember correctly, from what I saw in the published package, you are letting your package manager handle what files to publish. I think that may be causing it to hoist the files that are being used to the root. Try using the files property in package.json to declare what specific files you want to include in the published package. That should make it also respect your folder structure
Edited
  • reply
  • like
I think you're right. Basically - I'm running into the edges of my understanding and didn't really understand why babel was moving files to the root -- I've been playing with this all day and think I got a good solution. First it started just by moving gatsby-* into the src file because then babel would transpile that too.
  • reply
  • like
Now though, I'm working on a typescript adaptation, and so will likely be using your trick to import the files that are built in dist/
  • reply
  • like
Ohh, you’re using Babel. I only ever use Babel as a step in bundling, so I’m really not very familiar with using it directly, since I really dislike writing in straight Javascript. Couldn’t say without some research, and seeing the configuration, why it’s doing that. At the very least, you’d think it would change the imports. Personal opinion: Typescript is a better method to use anyway. Enforces stricter coding standards, and the source, if written properly, is basically self-documenting.
  • reply
  • like
Not to mention, if you use Typescript, you can make it a lot easier for consumers to use your plugin. Check out this starter if you’re interested in seeing one way you can use the generated types. Look at gatsby-config.ts in the .gatsby folder in particular
Edited
  • reply
  • like
Cool! Yeah, I was using babel because that's actually what the tutorial is based on. Oooh! that .gatsby folder is nice!
  • reply
  • like
Had some weirdness around the exports with commonjs, but I think because I'm now using Typescript, I can use ES Modules (? that sound right)? which solved that issue. -- Basically, I ran into this: https://stackoverflow.com/questions/35758584/cannot-redeclare-block-scoped-variable-typescript
  • reply
  • like
Yeah, you can just use ES modules now. TSC will take care of converting everything over
  • reply
  • like
Basically what happens if you don't use ES imports is that it assumes the file is not a module, and loads everything into the global scope. If you declare a variable in one file that's like this, but also declare the variable in another file (that also isn't being defined as module), then you get that error.
If you do much ambient declarations, this module business will sometimes become a problem, because you sometimes want to extend styles from other files, but as soon as you say "import this type from this file", it becomes a module, and is no longer ambient (i.e. to use the types you defined in that file, you would then have to import them as if they're a module, instead of just having access to them globally). To get around that (and since you can't use require() to import types), you can import them using the old TS triple-slash directive syntax /// <reference path="..." />.
Edited
  • reply
  • like