Future plans

[sindresorhus]

I got out v5 at last, which switched from PhantomJS to Puppeteer. This was an important release as PhantomJS is no longer maintained. Because of this, I tried to keep the breaking changes to a minimum. There are however lots of improvements I would like to do to the API, but which can be done sometime in the future. Here are some rough ideas:

Options:

• transparent => defaultBackground and make it true by default (since it's inverted)
• username => authentication.username
• password => authentication.password
• scale => scaleFactor and change the default value from 1 to 2
• crop => fullPage and make it true by default (since it's inverted)
• format => type (and value jpg => jpeg)
• selector => element
• css => styles and accept type string[] instead of string
• script => scripts and accept type string[] instead of string
• hide => hideElements and accept type string[] instead of string

API:

• .src() => .source()
• .dest() => .destination()

---

I would also like to move away from the chainable API to a single method call.

Before

const Pageres = require('pageres');

(async () => {
	await new Pageres({delay: 2})
		.src('https://github.com/sindresorhus/pageres', ['480x320', '1024x768'], {crop: true})
		.src('https://sindresorhus.com', ['1280x1024', '1920x1080'])
		.dest('output')
		.run();
})();

After

const pageres = require('pageres');

(async () => {
	await pageres({
		sources: [
			{
				url: 'https://github.com/sindresorhus/pageres',
				sizes: ['480x320', '1024x768'],
				// These options override the global ones
				delay: 4
			}
		]
		destination: 'output',
		delay: 2
	});
})();

Thoughts?

---

Open questions

• Should we make '480x320' => {width: 480, height: 320}? Or support both?
• Should sources item specific options be top-level in the source object (like in the above example) or nested inside {options: {delay: 4}}?

[sunitJindal]

Should we make '480x320' => {width: 480, height: 320}? Or support both?

The current input style is also common way of addressing the screen sizes, hence no harm in keeping it. And using the object notation would make the input more explicit.

If both notations are kept, it'll give new users flexibility to choose between these 2 options and users upgrading from previous versions will still have their scripts working with old input format.

My input: Keep both

[Kristinita]

Maybe it would be nice to add cwd option, that Grunt users can simply set URLs list without duplicates? It may help for users, that use pageres for current site visual testing.

Example:

• Before:

urls: ["site/dev/index.html"
        "site/dev/KiraFirstPath/KiraFirstFile.html"
        "site/dev/KiraSecondPath/KiraSecondFile.html"]

• After:

cwd: "site/dev/"
urls: ["index.html"
        "KiraFirstPath/KiraFirstFile.html"
        "KiraSecondPath/KiraSecondFile.html"]

Thanks.

[sindresorhus]

@Kristinita You can already do that with Grunt: https://gruntjs.com/configuring-tasks#building-the-files-object-dynamically

[Kristinita]

@sindresorhus, type:reply

You can already do that with Grunt: https://gruntjs.com/configuring-tasks#building-the-files-object-dynamically

Docs says about files object, but for custom plugins options (as grunt-pageres urls option) similar formats doesn't work.

For example, this configuration:

urls: [
        expand: true
        cwd: "site/dev/"
        src: ["index.html"
            "KiraFirstPath/KiraFirstFile.html"
            "KiraSecondPath/KiraSecondFile.html"]
        ]

or this:

urls:
    files: [
        expand: true
        cwd: "site/dev/"
        src: ["index.html"
            "KiraFirstPath/KiraFirstFile.html"
            "KiraSecondPath/KiraSecondFile.html"]
        ]

will not work.

Thanks.

[sindresorhus]

@Kristinita Good point. Yes, we should support the standard src property in grunt-pageres for local files.