Yes. One pro with this approach that while the tile is replaced with a sprite it's trivial to check collision between that and other sprites allowing you to jump under enemies and destroy them. Right now crushing a brick won't kill an enemy above the brick because I just remove the tile. This could be solved to do exactly as when bumping the brick but setting the alpha of the temporary sprite to 0.

You have to dig in the code and that part is a bit messy I think. A callback is fired when Mario collides with a tile, if he moves upwards and the collision is from above it will hide the tile and put a sprite at its position which is tweened up and down. When the sprite has returned to the original position it's removed again and the tile is made visible (don't remember if I use alpha on the tile or something else for this). The sprite is called SMBTileSprite which is a stupid name not to confuse with Phasers tileSprites. The implementation isn't that great. If I remember correctly there can currently only be one sprite of this kind, and this sprite should be in a pool to allow multiple simultaneous animations.

Thanks. I thought really hard before I came up with the idea of mushrooms, pipes and fireflowers ;-).
Nothing is forcing the canvas to 1600px. The size is determined by main.js (game size), some css in index.html (margin and stuff) and then the titleScene (scale canvas to fit).

@mistertabasco I use an Spriteatlas for most sprites but Mario is still in that spritesheet because I've prioritized other stuff with the little time I got. I suggest that you study the folder structure in raw assets and try texture packer. The key is generated from the path and filename. Why not practise by splitting up the Mario sprites in a folder, generate an updated Spriteatlas from that and share it ;-).

I just pushed a long overdue update to the GitHub repository. The source code itself is untouched but it now runs on Phaser 3.12 and Babel 7.
I noticed that this introduced some issues related to Arcade Physics. I wouldn't say that the controls were tight before, but they are definitely less tight now. There is an issue when trying to walk into a wall (like a pipe) and when you enter a pipe the horizontal velocity might make Mario fly away. The attract mode is a bit broken, but since deterministic physics where introduced in Phaser 3.10 or something, it could also be improved beyond what it has been.
I won't have time to update the repository any time soon, but I gladly accept pull request fixing anything of the issues above if you feel up to it.

You could set a callback for the tiles, make a collision test of your own in the callback function. If all sides of the tile should be collidable, return true immediately, otherwise check where the tile is overlapped and return true only if it's where it's solid (maybe just check for collisions, and if it reach the end of the function return false). I never used Tiled in that way but you should be able to navigate through the tilemap object (or cache) to find the information you refer to and implement that in your callback.

I've done some work on reorganizing and otherwise improve the code, but when the code got really messy (by the end of the Game create method) I lost focus a bit and couldn't resist implementing fire Mario. If you're using this, what would you prefer: Improved code base or additional features?
The online demo was also updated:

I made a repository with a starter project for creating Phaser 3 plugins (Phaser 3.8.0+):
Demo for testing your plugin with dat.gui integration for easy testing.
Build script to build uncompressed and minified versions of the plugin (with source map)
Webpack 4
ES6 support
This is a cleaned up version of what I've been using for my Grid Physics and Animated Tiles plugins.
Feedback and suggestions are appreciated.
Clone it with git: https://github.com/nkholski/phaser-plugin-starter

@B.Guyl The webpack-stuff of repository a clone of a Phaser 2 boilerplate which I've managed to get to work with Phaser 3 through trial and error. I'm not a great source for webpack best practises. 🙂 (1) No idea. It's just kept as it was in the original repository. (2) I don't really understand the question. I prefer a source folder with content that should be transpiled, a static folder and a build folder that everything get copied to. I load the assets with the Phaser 3 file loader. (3) @snowbillr got you covered 🙂

I'm using the es6-version. Great work. Sometimes it seems that it fails to wait for all imports though. I'm working with a button class and get this error now and then "menu.js:35 Uncaught TypeError: _button2.default is not a constructor" which resolves if I just save the file with the button class again unaltered.
It was a thread here about making an official template. I think that's a great idea and maybe this could be a candidate? How does the build compare to webpack? I think an official template would get much more attention from the community, with examples on how to extend it and PRs to keep dependencies up to date.