Masonite 2.3
Masonite 2.3 brings a lot of code and quality of life improvements. There aren't a lot of major ground breaking changes and depending on how your application is structured, may not require much effort to upgrade.
Below is a list of changes that will be in Masonite 2.3:
Some larger changes include all packages for Masonite use SEMVER versioning while Masonite still using ROMVER as it has been since Masonite started.
Masonite will also not require any packages for you through Masonite requirements and will instead put the requirements in the requirements.txt file in new projects. This will allow packages to release new Majors outside of the major upgrades of Masonite. So we can develop new package improvements faster.
The masonite.testing.TestSuite class has been completely removed. This was a class that was obsolete and has been replace by the masonite.testing.TestCase class anyway. The TestSuite class was bascially wrappers around some of the commands that predated the newer testing features.
Recently there has been a good amount of talks about the limitations of compiling sass with the Python libsass provider. Because of these limitations, Masonite 2.3 will remove it completely.
A Laravel Mix file will now come with new installed applications created by craft.
The Responsable class will be able to be inherited by any class and be returned in the controller. If the class has a get_response() method then the class will be rendered using that method. The View class now acts in this way.
Masonite has always supported the previous 4 Python versions. Since the release of Python 3.8 recently, Masonite will now only support Python 3.5, 3.6, 3.7 and 3.8. When Python 3.9 comes out, Python 3.5 will be dropped.
You can still use previous versions of Masonite if you need a previous supported Python version.
Masonite has moved away from the Auth class and towards Guard classes. These classes will be responsable for handling everything from getting the user to handling logging in and logging out.
There is also a much better way to register new guards so packages will be able to register their own guards with your app which you can then use or swap on the fly.
This is a very small change but will save a lot of time when upgrading your application. Now anytime you resolve the Auth class you will get an instance of a Guard class instead. The use of both classes are identical so they should just work as is.
(This swap may be removed in Masonite 2.4+)
All the authentication stuff in the previous improvements have been abstracted to their own provider so you will need to a add a new provider to your providers list.
The Auth class now contains a new method which returns a list of routes. This cleans up the web.py file nicely when scaffolding.
The container can not longer have modules bound to it. These should instead be imported.
Added a few new assertion methods to help chaining methods and keeping tests short and fast. These include assertHasHeader and assertNotHasHeader.
Added a new download class to make it very easy to force downloads or display files.
This is used like this:
from masonite.response import Download​def show(self):return Download('/path/to/file', force=True)
Forcing will make the file download and not forcing will display the file in the browser.
You can now run a craft preset command which will generate some .json files and example templates. There is a react, vue and bootstrap preset currently.
Instead of a url like /?filter[name]=Joe&filter[user]=bob&[email protected]
parsing to:
{"filter[name]": "Joe","filter[user]": "Bob","email": "[email protected]"}
It will now parse into:
{"email": "[email protected]","filter": {"name": "Joe","user": "bob"}}
Parsing the query to the original way is no longer possible. This also comes with a query_parse helper which you can use to parse a query string the same way Masonite does.
The container has a helpful collect method which allows you to collect all the classes in the container with a certain key or an instance of a class like this:
app.collect('*Command')
Will collect everything in the container where the binding key ends with Command.
You can also collect everything that is a subclass:
from masonite.response import Responsable​app.collect(Responsable)
This will collect everything that is a subclass of Responsable
This has now been expanded to also include instances of. So it will work for objects now and not just classes.
This is an internal change mostly and completely transparent to all who install Masonite. This allows installing third party packages into Masonite with the same namespace without namespace conflicts.
Masonite now handles the response as bytes. This allows for different classes to handle the response in different ways.
Previously Masonite ultimately converted everything to a string at the end but some things needed to be returned to the WSGI server as bytes (like the new file download feature). So if you need to handle the raw response then you will now expect bytes instead of a string.
The Scheduler has a few changes.
There are a few new methods on the tasks you can use like every, every_minute, every_15_minutes, every_30_minutes, every_45_minutes, daily, hourly, weekly, monthly.
These can either be used inside the provider or inside the command to make a more expressive scheduling syntax.
Providers can now inherit the CanSchedule class which gives it access to the new self.call() method (which is used to schedule commands) and self.schedule() method (which is used to schedule jobs).
These are really just helper methods to help bind things to the container more expressively.
You can now schedule jobs or commands in a new expressive way. In addition to setting the schedule interval as attributes on the Task you can now do it directly in the provider:
def register(self):self.call('your:command --flag').daily().at('9:00')self.call('your:command --flag').every_minute()self.schedule(YourJob()).every('3 days')
There are several other methods that will be documented on release.
We also changed the namespace from scheduler to masonite.scheduler. So you will need to refactor your imports.
There are now mailable classes which you can use to wrap some of the logic of building emails around. Instead of doing something like this:
mail.to('[email protected]').reply_to('[email protected]').template('emails.register').subject(..).send()
You can now do:
from app.mailables import RegistrationMailablemail.mailable(RegistrationMailable()).send()
Now you can simply return a tuple if you want to change the status code that gets returned.
For example before we had to do something like this:
def show(self, response: Response):return response.json({'error': 'unauthenticated'}, status=401)
Now you can simply return a tuple:
def show(self):return {'error': 'unauthenticated'}, 401
Previously we converted the response to a string when the request was finished but this prevented use cases where we wanted to return bytes (like returning an image or PDF). Now the conversion is happens (or doesn't happen) internally before the WSGI server needs to render a response. This results in a slight change in your application.
The CLI tool no longer needs to be installed as the first step. Now the first step would be to install masonite which will give you access to craft. From there you can create a new project.
Masonite API now uses the from masonite.api. namespace rather than the previous from api.
