plugin -> local to published: somethings breakingFebruary 17, 2020 at 12:12am (Edited 2 months ago)
I just published a new source plugin (https://www.npmjs.com/package/gatsby-source-xkcd) and when I try to update my
gatsby-configfile to use it from the temporary local link using
to installing it via NPM and then referring to just the package:
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-nodefile needed to be in the root, but looking at examples of other respositories, they were in a
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-nodeis importing a file from
./src/createNodeDataand one from
srcdirectory doesn't exist in the distributed package
npm pack gatsby-source-xkcd, and then unpacking the tarball that gets downloaded. Check out the code there.
What I like to do is write my source code in the
srcdirectory, and then the build dumps all of the transpiled (and otherwise processed) source into
dist. All my
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.
Oh, and btw, the
gatsby-*files do need to be in the project root. Otherwise, Gatsby won't be able to find them.
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...).
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.
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
package.jsonto declare what specific files you want to include in the published package. That should make it also respect your folder structure
I think you're right. Basically - I'm running into the edges of my understanding and didn't really understand why
babelwas 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
srcfile because then
babelwould transpile that too.
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
Cool! Yeah, I was using
babelbecause that's actually what the tutorial is based on. Oooh! that
.gatsbyfolder is nice!
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
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="..." />.