How to upgrade to v1.4.0

[s-kris]

Hello..

I tried to manually upgrade from 1.3.0 to 1.4.0 following the git log. Is there any an easy way please?
thank you.

[kiuKisas]

Look at the new Elderjs/template, package.json. you should have a new script `dev`. The two main change are dynamic routes and unification of elder and roll up, so the scrip to start elder change. Le sam. 15 mai 2021 à 19:03, Sai Krishna ***@***.***> a écrit :

…

Hello.. I tried to manually upgrade from 1.3.0 to 1.4.0 following the git log. Is there any an easy way please? thank you. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#174>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADA4KPENE6NRJPMAIB3TCK3TN2SOPANCNFSM446CBJ7A> .

[s-kris]

Thanks @kiuKisas. I got that done.
I was asking to have an easy way to upgrade generally with instructions for prod codebases. Just to be safe.

[nickreese]

@s-kris I updated the release notes: https://github.com/Elderjs/elderjs/releases/tag/1.4.0

[nickreese]

@s-kris See the release notes: https://github.com/Elderjs/elderjs/releases/tag/1.4.0

Basically this change shouldn't be breaking for most people in prod unless you're using the middleware hook. Everything else is backwards compatible.

For development, I refactored to npm run dev:rollup and npm run dev:server into a single process.

[s-kris]

Thank you Nick!! :)

[kiuKisas]

Maybe we should move some code from the template to the main repo to avoid those kind of confusion.

Quick though on it, we can:

• merge svelte.config.js and rollup.config.js to elder.config.js, through keys svelte and rollup respectively.
  In fact, as I don't think lots of use need to change it, the actual behaviour can be default and the user should be able to override it through these keys if needed.

• src/build.js and src/cleanpublic.js should be easy to integrate to the core, I don't see any reason to change them on the user side. Also, does build:html script is actually useful ?

• src/server.js can also be integrate to elder.config.js, through a server key I guess. The user should be able to change it (example, using polka-next or an other server instead), but most of use will not edit these part. Need more though about it, a rough draft of what I think can be:

// Default behavior
server:  {
  type: 'polka',
  options: {
    cors: true,
    compression: 6,
    ...
  }
}

// OR, for a more custom server :

// Where the elder argument is:
// const { Elder } = require('@elderjs/elderjs');
//const elder = new Elder({ context: 'server' });
 
server: (elder) => {
// Custom server call
}

This way, the template would only be made of:

• an elder.config.js

• src folder with hooks.js and shortcode.js, routes and components folder.

If we are going this direction, we can even make hooks.js and shortcode.js optional, and include copyAssetsToPublic as an internal hook to elderjs.

With these changes, a quick start guide without a template may also be easy to write.

[nickreese]

@kiuKisas I like the idea of having a quick start guide, but moving each of these into the core results in less flexibility for most projects. It may appeal to beginners more, but I think mid level devs will be more comfortable when things are obvious.

If the goal is to appeal to beginners I'd rather spend the effort building a full fledged blog template, with email subscribe, etc.

Notes on each:

• The goal of keeping svelte.config.js and rollup.config.js separate is to minimize magic and give users full control over their project. It also keeps the complexity down on our end. As long as the user has something like below in their rollup.config.js then they'll pickup future changes. For example on each of my projects we have other rollup configs that we use in addition to the Elder.js one.

const { getRollupConfig } = require('@elderjs/elderjs');
const svelteConfig = require('./svelte.config');
module.exports = [...getRollupConfig({ svelteConfig })];

• Build could be moved into the core but then we'd probably want to offer a CLI to trigger it. I'm more of the opinion that keeping things obvious is the right move. Most of our internal projects trigger something before/after build, that is why it was built this way.

• server with most devs having at least some experience with express, hapi, polka, fastify, etc. Having this be obvious is key. It allows for easy implementation of sessions and any other middleware in SSR mode. For instance in one of our installs we run Elder.js in SSR mode with a postgraphile middleware that powers querying things on the client and data piping on the server. I fear moving these into the core would make things easier for beginners but slow down power users.

[kiuKisas]

Seems legit :) Le dim. 16 mai 2021 à 17:48, Nick Reese ***@***.***> a écrit :

…

@kiuKisas <https://github.com/kiuKisas> I like the idea of having a quick start guide, but moving each of these into the core results in less flexibility for most projects. It may appeal to beginners more, but I think mid level devs will be more comfortable when things are obvious. If the goal is to appeal to beginners I'd rather spend the effort building a full fledged blog template, with email subscribe, etc. Notes on each: - The goal of keeping svelte.config.js and rollup.config.js separate is to minimize magic and give users full control over their project. It also keeps the complexity down on our end. As long as the user has something like below in their rollup.config.js then they'll pickup future changes. For example on each of my projects we have other rollup configs that we use in addition to the Elder.js one. const { getRollupConfig } = ***@***.***/elderjs');const svelteConfig = require('./svelte.config');module.exports = [...getRollupConfig({ svelteConfig })]; - Build could be moved into the core but then we'd probably want to offer a CLI to trigger it. I'm more of the opinion that keeping things obvious is the right move. Most of our internal projects trigger something before/after build, that is why it was built this way. - server with most devs having at least some experience with express, hapi, polka, fastify, etc. Having this be obvious is key. It allows for easy implementation of sessions and any other middleware in SSR mode. For instance in one of our installs we run Elder.js in SSR mode with a postgraphile middleware that powers querying things on the client and data piping on the server. I fear moving these into the core would make things easier for beginners but slow down power users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#174 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADA4KPEVKYKSQ2JQ2C3I6N3TN7SMHANCNFSM446CBJ7A> .

[s-kris]

People.. I upgraded my second codebase today and started seeing errors in dev.
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client

But here's the thing, kindly observe how the errors popup upon on route navigation.

> Elder.js running on http://localhost:3000
elder-plugin-sitemap please make sure you have a full domain name set for the value at 'elder-plugin-sitemap.origin' in your elder.config.js.
/fix-gatsby-build-getting-stuck-at-source-and-transform-nodes-ckl1qg9g7056217nstheb5lhd/
/
/how-to-disable-netflix-autoplaying-trailers-on-homepage-ckn4nhzgw014728o095eqkn4d/
/how-to-disable-netflix-autoplaying-trailers-on-homepage-ckn4nhzgw014728o095eqkn4d/ [
  Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
      at new NodeError (node:internal/errors:329:5)
      at ServerResponse.setHeader (node:_http_outgoing:579:11)
      at setHeadersFromObject (/<local_path>/node_modules/on-headers/index.js:94:16)
      at ServerResponse.setWriteHeadHeaders (/<local_path>/node_modules/on-headers/index.js:122:5)
      at ServerResponse.writeHead (/<local_path>/node_modules/on-headers/index.js:30:36)
      at send (/<local_path>/node_modules/sirv/build.js:87:6)
      at Array.<anonymous> (/<local_path>/node_modules/sirv/build.js:177:3)
      at loop (/<local_path>/node_modules/polka/index.js:95:56)
      at next (/<local_path>/node_modules/polka/index.js:94:63)
      at handleRequest (/<local_path>/node_modules/@elderjs/elderjs/build/routes/prepareRouter.js:114:16) {
    code: 'ERR_HTTP_HEADERS_SENT'
  }
]
/
/ [
  Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
      at new NodeError (node:internal/errors:329:5)
      at ServerResponse.setHeader (node:_http_outgoing:579:11)
      at setHeadersFromObject (/<local_path>/node_modules/on-headers/index.js:94:16)
      at ServerResponse.setWriteHeadHeaders (/<local_path>/node_modules/on-headers/index.js:122:5)
      at ServerResponse.writeHead (/<local_path>/node_modules/on-headers/index.js:30:36)
      at send (/<local_path>/node_modules/sirv/build.js:87:6)
      at Array.<anonymous> (/<local_path>/node_modules/sirv/build.js:177:3)
      at loop (/<local_path>/node_modules/polka/index.js:95:56)
      at next (/<local_path>/node_modules/polka/index.js:94:63)
      at handleRequest (/<local_path>/node_modules/@elderjs/elderjs/build/routes/prepareRouter.js:114:16) {
    code: 'ERR_HTTP_HEADERS_SENT'
  }
]

[s-kris]

haha nick! I just found it. looks like you posted it :D
Thank you!

[nickreese]

Change is live on npm.

[s-kris]

@nickreese
by returning res.end(html), the following error is thrown.

/
Received attempted mutation on "middleware" from "elderExpressLikeMiddleware" on the object "_writeState". _writeState is not mutable on this hook  { type: 'internal', addedBy: 'elder.js' }

we should probably do

res.end(html);
return;

[nickreese]

@s-kris Shipped.

[s-kris]

Awesome!